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Abstract 


This  report  describes  progress  in  research  on  an  autonomous  robot  for  planetary  exploration 
performed  during  1989  at  the  Robotics  Institute,  Carnegie  Mellon  University.  The  report  begins 
with  an  introduction,  summary  of  achievements,  and  lists  of  personnel  and  publications.  It  also 
includes  several  papers  resulting  from  the  research. 

The  research  program  includes  a  broad  agenda  in  the  development  of  an  autonomous  mobile 
robot.  In  the  year  covered  by  this  report,  we  addressed  two  key  topics: 

Six-Legged  Walking  Robot  —  To  overcome  shortcomings  exhibited  by  existing  wheeled  and 
walking  robot  mechanisms,  we  configured  the  Ambler  as  a  walking  robot.  The  fundamental 
advantage  of  the  Ambler  configuration — which  has  implications  for  efficiency,  mechanism 
modeling,  and  control  simplicity — is  that  actuators  for  body  support  arc  independent  of 
those  for  propulsion;  a  subset  of  the  planar  joints  propel  the  body,  and  the  vertical  actu¬ 
ators  support  and  level  the  body  over  terrain.  During  1989  we  configured,  designed,  and 
constructed  the  Ambler.  In  addition,  we  developed  models  of  its  dynamics,  and  studied 
leveling  control. 

Integrated  Single  Leg  Walking  —  We  implemented  and  tested  an  integrated  system  capable  of 
walking  with  a  single  leg  over  rugged  terrain.  A  prototype  of  an  Ambler  leg  is  suspended 
below  a  carriage  that  slides  along  rails.  To  walk,  the  system  uses  a  laser  scanner  to  find  a 
clear,  flat  foothold,  positions  the  leg  above  the  foothold,  contacts  the  terrain  with  the  foot, 
and  applies  force  enough  to  advance  the  carriage  along  the  rails.  Walking  both  forward 
and  backward,  the  system  has  traversed  hundreds  of  meters  of  rugged  terrain  including 
obstacles  too  tall  to  step  over,  trenches  too  deep  to  step  in,  closely  spaced  rocks,  and  sand 
hills.  In  addition,  we  conducted  preliminary  experiments  with  concurrent  planning  and 
execution,  and  developed  a  leg  recovery  planner  that  generates  time  and  power  efficient 
3D  trajectories  using  2D  search. 

Mobile  Manipulation  with  Hero  Robot  —  Indoor  mobile  manipulator  tasks  include  collecting 
cups  from  the  lab  floor,  retrieving  printer  output,  and  recharging  when  its  battery  gets  low. 
The  robot  monitors  its  environment,  and  handles  exceptional  conditions  in  a  robust  fashion. 
For  example,  it  uses  vision  to  track  the  appearance  and  disappearance  of  cups,  uses  on¬ 
board  sonars  to  detect  imminent  collisions,  and  monitors  battery  level  periodically. 

This  research  is  primarily  sponsored  by  the  National  Aeronautics  and  Space  Administration. 
Portions  of  this  research  are  also  supported  by  the  National  Science  Foundation  and  the  Defense 
Advanced  Research  Projects  Agency. 
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Introduction 


This  report  reviews  progress  during  1989  at  the  Robotics  Institute,  Carnegie  Mellon  University, 
on  research  sponsored  by  NASA  titled  “Autonomous  Planetary  Rover.”  This  report  begins  with 
an  overview  and  a  summary  of  achievements.  It  then  lists  the  members  of  the  research  group 
supported  by,  or  directly  related  to  the  contract,  and  their  publications.  Finally,  it  includes  three 
detailed  papers  representativ^f  specific  areas  of  research. 


Overview 
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The  ewtr program  to  develop  an  Earth-based  prototype  of  an  autonomous  planetary  rover  is 
organized  around  three  teams  that  are  developing  the  locomotion,  perception,  and  planning  sub¬ 
systems.  A  joint  task  is  to  integrate  the  three  subsystems  into  an  experimental  robot  system.  We 
will  use  this  system  for  evaluating,  demonstrating,  and  validating  the  concepts  and  technologies 
developed  in  the  program. 

The  technical  objectives  of  the  research  include  the  following: 

( \  To  develop  and  demonstrate  an  autonomous  Earth-based  mobile  robot  that  can  survive, 
explore,  and  sample  in  rugged,  natural  terrains  analogous  to  those  of  Mars^ 

^  To  provide  detailed,  local  representations  and  broad,  3-D  descriptions  of  rugged,  unknown 
'  terrain  by  exploiting  diverse  sensors  and  data  sources^ 

3)  To  demonstrate  robot  autonomy  through  a  planning  and  task  control  ar^ite^ture  that^ 
incorporates  robot  goals,  intentions,  actions,  exceptions,  and  safeguards.  - 

.  I  »  .  .  I  '-t-  .  •  ,  'A 
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Accomplishments 


7 


This  section  describes  key  accomplishments  of  the  project  research  from  January  1989  to  De¬ 
cember  1989.  We  present  these  accomplishments  in  three  parts:  the  first  includes  all  activities 
related  to  construction  of  the  Ambler' ;  the  second  includes  those  activities  related  to  integrated 
walking;  the  third  covers  other  activities. 

‘An  acronym  for  Autonomous  MoBiLe  Exploration  Robot 


Figure  1:  Ambler  configuration 


Ambler 

A  major  accomplishment  of  1989  was  to  reconfigure,  design,  and  build  the  six-legged  walking 
machine.  Using  all  six  legs,  we  demonstrated  body  motion  (lift,  advance)  and  leg  recovery 
(circulation  between  stacks).  These  first  steps  of  the  Ambler  are  a  significant  project  milestone. 

Configuration  —  We  reconfigured  the  earlier  Ambler  designs  to  have  two  stacks,  with  six 
circulating  legs  (Figure  1).  Each  leg  is  a  rotary-prismatic-prismatic  orthogonal  leg.  The 
configuration  enables  level  body  motion,  a  circulating  gait,  conservatively  stable  gaits, 
high  mobility,  and  many  sampling  deployment  options. 

Design  —  We  detailed  the  relative  leg  link  scale,  duplicated  components  when  possible,  and 
augmented  our  efforts  with  results  from  a  prototype  leg  testing  program.  Also  in  the 
design  process  we  identified  worst  cases  for  structural  loads,  drivetrain  loads,  power,  and 
link  speeds.  We  made  a  number  of  key  design  decisions:  to  use  aluminum  as  our  primary  t 

material;  to  equip  all  axes  with  spur  gear  drives;  to  outfit  the  prismatic  links  with  linear 
bearings;  to  incorporate  separate  slipring  units  in  each  leg;  to  have  shoulders  ride  not 
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on  each  other  but  on  a  central  shaft;  and  to  construct  the  superstructure  from  aluminum 
instead  of  composites. 

Fabrication  —  As  we  completed  designs,  we  began  fabrication  but  continued  to  alter  them 
slightly  to  simplify  assembly.  An  intensive  effort  to  put  all  the  pieces  together  culminated 
in  a  complete  vehicle  in  December. 

Electronics  and  Sensing  —  We  designed  and  implemented  a  variety  of  electronic  devices  to 
link  computing,  actuation,  and  the  physical  mechanism.  We  established  signal  paths  to 
provide  machine  status — including  drive  train,  positions,  and  forces — to  computing.  To 
reduce  the  number  of  cables  required,  we  designed  and  built  a  high-speed  multiplexor  that 
provides  real-time  data  transmission  of  analog  and  digital  signals.  We  built  a  tether  to 
carry  all  signals  to  and  from  the  machine.  The  tether  is  46m  of  protective  fabric  sheathing 
that  contains  130  shielded  twisted  pairs,  30  coaxial  cables,  and  power  cables.  To  ensure 
safe  operation  of  the  machine,  we  implemented  a  three  state  finite  state  machine  safety 
circuit  that  allows  manual  control,  computer  control,  and  provides  graceful  termination 
upon  certain  conditions. 

Real-Time  Controller  —  We  have  developed  a  real-time  controller  based  on  VME  hardware 
and  the  VxWorks  operating  system.  Multiple  processors  synchronize  input/output  and 
motion  control.  Creonics  motion  control  cards  receive  encoder  feedback  and  amplifier 
status  signals,  and  transmit  motor  command  and  amplifier  control  signals.  Digital  boards 
route  signals  for  brake  control,  the  safety  circuit  interface,  and  force  sensor  control.  Up 
to  64  A/D  converter  channels  read  signals  from  the  force  sensors,  absolute  encoders,  and 
inclinometers. 

Mechanism  Modeling  —  We  formulated  two  models  for  the  Ambler  mechanism;  a  com¬ 
prehensive  model  and  a  planar  model.  The  comprehensive  model  incorporates  non¬ 
conservative  foot-soil  interactions  in  a  full  non-linear  dynamic  formulation.  We  employed 
it  for  performance  evaluations  such  as  assessment  of  power  consumption,  potential  for 
tipover,  and  foot  slippage,  and  continue  to  use  it  to  develop  body  leveling  control  algo¬ 
rithms,  We  used  the  second,  planar  model  to  evaluate  mechanism  designs  and  to  investigate 
joint  driving  configurations  for  propulsion. 
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Figure  2:  Single  leg  testbed 


Integrated  Walking 

We  implemented  and  tested  an  integrated  system  capable  of  walking  with  a  single  leg  over 
rugged  terrain.  A  prototype  of  the  Ambler  leg  is  suspended  below  a  carriage  that  slides  along 
rails  (Figure  2).  To  walk,  the  system  uses  a  laser  scanner  to  find  a  foothold,  computes  an  efficient 
trajectory  to  the  foothold,  contacts  the  terrain  with  the  foot,  and  applies  force  enough  to  advance 
the  carriage  along  the  rails.  Walking  both  forward  and  backward,  the  system  has  traversed 
hundreds  of  meters  of  rugged  terrain  including  obstacles  too  tall  to  step  over,  trenches  too  deep 
to  step  in,  closely  spaced  rocks,  and  sand  hills.  The  implemented  system  consists  of  a  numbei 
of  task-specific  processes  (two  for  planning,  two  for  perception,  one  for  real-time  control,  briefly 
described  below)  and  a  central  control  process  that  directs  the  flow  of  communication  between 
processes.  With  this  system  we  experimented  with  extensions  to  suppon  concurrency  and  error 
recovery. 
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Task  Control  Architecture  —  We  implemented  the  Task  Cono-ol  Architecture  (TCA)  and  used 
it  to  integrate  the  various  components  of  the  walking  system.  TCA  provides  a  number 
of  important  facilities  for  building  and  operating  complex  robot  systems.  In  particular,  it 
provides  mechanisms  to  support  message  passing  between  distributed  processes,  hierarchi¬ 
cal  planning,  plan  execution,  monitoring  the  environment,  and  exception  handling.  Using 
TCA  the  system  consists  of  a  number  of  task-specific  processes  and  a  central  control 
process  that  directs  the  flow  of  communication  between  modules. 

Real-Time  Controller  —  We  implemented  a  real-time  control  system  for  the  single  leg.  This 
system,  which  runs  under  the  VxWorks  operating  system,  communicates  via  the  TCA, 
moves  the  leg  and  carriage  and  reports  their  positions,  and  handles  asynchronous  interrupts 
generated  by  the  Creonics  motion  control  boards. 

Perception  using  Elevation  Maps  —  We  implemented  a  perception  system  to  build  elevation 
maps  from  sequences  of  range  images.  In  addition  to  the  elevation,  the  system  computes 
the  elevation  uncertainty,  local  slope,  visibility,  and  foothold  goodness  (measure  of  ter¬ 
rain  flatness  in  a  foot-size  neighborhood).  The  system  executes  approximately  20  x  10^ 
instructions  to  build  a  400  point  map.  In  parallel,  we  developed  techniques  for  matching 
long  sequences  of  range  images  and  for  merging  them  stochastically  into  a  composite  map 
(Figure  3),  and  conducted  experiments  in  updating  satellite  maps  from  local  data. 


Figure  3:  Composite  elevation  map 

This  map  was  built  by  matching  125  Erim  range  images  acquired  by  the  Autonomous  Land  Vehicle  as  it 
traversed  a  40m  path  (right  to  left),  including  a  30  degree  left  turn,  at  an  outdoor  site  in  Colorado.  The 
matching  between  consecutive  range  images  was  performed  by  first  matching  features  to  obtain  an  initial 
estimate  of  the  displacement,  and  then  using  that  estimate  to  seed  an  iterative  minimization  procedure. 
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Planning  —  We  developed  and  implemented  two  planning  modules:  the  Gait  Planner  and  the 
Leg  Recovery  Planner.  The  Gait  Planner  determines  leg  sequencing,  body  trajectory,  and 
foothold  location.  The  Leg  Recovery  Planner  generates  trajectories  that  avoid  obstacles  and 
minimize  an  objective  function  of  time  and  energy.  It  plans  three-dimensional  trajectories 
while  searching  a  two-dimensional  space,  which  reduces  computation  time  substantially. 

Single  Leg  Walking  Experiments  —  We  conducted  a  series  of  experiments  and  demonstra¬ 
tions  using  the  Single  Leg  Testbed.  For  the  first  stage  of  testing,  we  levelled  the  terrain  and 
did  not  alter  it  between  runs.  We  began  with  a  minimal  set  of  processes,  and  incrementally 
added  processes.  For  the  second  stage  of  testing,  we  executed  the  same  processes,  and 
walked  over  different  terrains.  We  began  with  level  ground,  and  graduated  to  succes¬ 
sively  more  difficult  terrain.  Figure  4  shows  an  obstacle  course  that  the  integrated  system 
traversed  more  than  30  times,  and  the  elevation  map  built  by  the  perception  system. 


Figure  4:  Obstacle  course 

The  obstacle  course  consists  of  a  small  obstacle  (upside  down  basket,  lower  right),  a  box  (right)  too  tall 
for  the  leg  to  step  over,  a  “steeplechase”  arrangement  of  pylons  (center)  lying  on  the  ground,  two  larger 
obstacles  (left  and  upper  center)  separated  by  about  Im,  and  a  dozen  or  so  smaller  obstacles. 

The  perception  system  built  this  elevation  map  from  approximately  five  range  images  acquired  at  different 
positions.  The  labels  indicate  metric  units  in  the  global  reference  frame,  where  0  <  .Y  <  3  and  4  <  F  <  12. 
The  map  resolution  is  10cm. 
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Other  Activities 


Mobile  Manipulator  Testbed  —  At  the  Mobile  Manipulator  Testbed  we  developed  and  tested 
advanced  TCA  features  such  as  monitors,  task  tree  management,  temporal  constraints, 
exception  handling,  and  resource  allocation.  Using  these  features,  a  Hero  robot  successfully 
demonstrated  several  tasks:  cup  collection,  retrieval  of  printer  output,  delivering  objects 
to  workstations,  recharging  its  battery,  using  on-board  reflexive  procedures  to  detect  and 
react  to  imminent  collisions.  We  also  achieved  substantial  progress  toward  a  number  of 
other  capabilities,  including  navigation  based  on  sonar,  learning  to  approach  and  recognize 
objects,  and  learning  stimulus-response  action  rules. 

Simulator  —  We  developed  a  simulation  system  on  a  Titan  supercomputer  (Figure  5).  Capa¬ 
bilities  include  three-dimensional  solid  and  kinematic  models  of  the  six-legged  Ambler, 
generation  and  display  of  synthetic  terrain  (rocks,  hills,  craters,  etc),  and  acquisition  of 
synthetic  range  images  of  terrain. 


Figure  5:  Simulated  Ambler  on  synthetic  terrain 
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INVERSE  DYNAMIC  MODELS  USED  FOR  FORCE  CONTROL  OF 
COMPLIANT,  CLOSED-CHAIN  MECHANISMS 


D.  J.  Manko  and  W.  L  Whittaker 
Field  Robotics  Center 
Carnegie  Mellon  University 
Schenley  Park,  Pennsylvania 


ABSTRACT 

A  general  inverse  dynamic  model  is  presented  that  is  applicable  to 
mechanisms  incorporating  member,  joint  and  base  compliance. 
Previous  approaches  for  defining  inverse  dynamic  models  of  compliant 
mechanisms  have  been  approximations  or  Umited  to  simple  mechanism 
geometries  and  open-chain  mechanisms.  Hence,  the  motivation  for  a 
more  general  approach.  Inverse  dynamic  equations  for  compliant 
mechanisms  modeled  with  and  without  constraint  equations  are  shown 
to  be  solvable  sets  of  dilTerendal/algebraic  equations  (DAE's);  relevant 
characteristics  and  solutions  of  DAE  systems  are  .discussed.  An 
imponant  application  for  inverse  dynamic  models  of  compliant 
mechanisms  is  model-based  foree  conool  of  closed-chain  mechanisms. 
The  formulation  and  solution  procedures  discussed  in  this  paper  have 
been  successfully  applied  to  model  legged  locomotion  on  natural 
terrain. 

1.  INTRODUCTION 

An  inverse  dynairtic  tirodel  of  a  mechanism  is  an  application  of  the 
equations  of  motion  for  a  system  where  joint  trajectories  are  defined, 
arid  the  actuator  forces  and  interaction  forces  required  to  produce  these 
motions  are  calculated.  Gn  contrast,  a  ftnwatd  dynamic  model  is  used 
to  calculate  mechanism  motions  in  response  to  a  set  of  applied  forces.) 
Calculations  of  these  forces  are  useful  for  sizing  members  and 
actuators  during  the  mechanism  design  phase.  Additionally, 
computationally  fast  versions  of  the  rtxxlel  can  be  incorporated  into 
model-based  control  schemes.  An  important  application  is  model- 
based  force  control  of  closed-chain  mechanisms  where  the  constraint  or 
interaction  forces  (e.g.,  foot  forces  for  a  walking  machine)  are  sampled 
quantities.  The  inverse  dynamic  rtxxlel  provides  estimates  of  these 
interaction  forces,  which  may  be  used  as  control  set  points. 

The  following  section  of  this  paper  discusses  existing  methods  for 
defining  inverse  dynamic  trxxlels  of  compliant  mechanisms.  A  general 
formulation  of  inverse  dynamic  trxxlels  for  compliant  mechanisms 
modeled  with  atxl  without  constraint  equations  is  described  in  Section 
3.  The  resulting  inverse  dynamic  equations  are  shown  to  be  sets  of 
differential/algetaaic  equations  (DAE's)  after  substitution  of  specified 
joint  nootions.  Relevant  characteristics  and  solution  procedures  for 
DAE  systettu  are  considered  in  Section  4.  The  system  index  (which 
correlates  with  solution  difficulty)  of  compliant  mechanism,  inverse 
dynamic  models  are  defined  in  Section  5  of  this  pap^,  identifying  the 
system  index  assures  that  stable  and  accurate  numerical  solutions  can 
be  calculated  by  the  methods  described  in  Section  4. 


Z BACKGROUND 

An  inverse  dynamic  nxxlel  is  obtained  by  substitution  of  specified 
coordinate  trajectories  into  the  equations  of  motion  developed  for  the 
system.  For  ixxi-compliant  mechanisms,  all  coordinate  trajectories  can 
be  specified  because  rigid  body  motions  completely  define  the  system 
kinematics.  Alternately,  inverse  dynamic  models  for  compliant 
mechaiusms  are  complicated  by  the  fact  that  trajectories  cannot  be 
specified  a  priori  for  the  deflection  variables  which  model  the  system 
compliance.  In  general,  deflection  variables  are  not  directly  controlled 
(Le.,  iqrplied  forces  equal  to  zero)  so  it  is  inappropriate  to  presume  that 
ixxrtions  of  a  deflection  variable  can  be  sprcifi^  Responses  of  the 
deflection  variables  are  unknown  quantities  that  are  nlculated  along 
with  the  required  actuator  forces  to  produce  the  specified  joint  motions. 

An  approximate  approach  for  formulating  inverse  dynamic  models 
of  compliant  irxxhaiusms  is  to  impose  inertial  loads  on  a  flexible,  static 
mechanism  model  for  deflection  calculations  [Dado  86}.  The  inertial 
loads  used  in  the  analysis  are  obtained  from  the  kinematics  of  the 
mechanism  considering  it  to  be  ideally  rigid.  Although  this  method  is 
relatively  simple  to  implement,  it  does  not  account  for  the  coupling 
between  joint  aixl  deflection  variables  which  limits  its  application  to 
relatively  slow  irxrving  mechanisms.  Also,  time  dependent  deflection 
response  is  not  considered. 

The  inverse  dynamic  model  for  a  compliant,  2  dof  cylindrical  arm 
[Forrest-Barlach  87]  was  obtained  by  substitution  of  dynamic 
equations  for  the  deflection  variables  (where  the  deflection  variables  are 
defined  as  functions  of  the  joint  variables)  into  the  remaining  dynamic 
equations  cormponding  to  the  joint  variables.  The  resulting  joint 
variable  equations  are  fourth  order  differential  equations  requiring  joint 
trajectory  planning  of  both  jerk  and  jerk  rate.  The  approach  of 
eli^nating  deflection  variables  from  the  equations  of  motion  can  only 
be  accomplished  for  relatively  simple  systems. 

The  finite  eleirrent  method  was  used  to  discretize  the  equations  of 
motion  for  open-chain  mechanisms  having  structural  flexibility  [Bayo 
88].  An  inverse  dynamic  model  was  obtained  by  specifying 
trajectories  for  a  subset  of  the  detlecnon  variables  which  decouples  the 
equations  for  an  individual  link.  Joint  torques  required  to  pr^uce  a 
desired  end  effector  motion  were  calculated  using  an  iterative  solution 
scheme.  Specification  of  trajectories  for  a  subset  of  the  deflection 
variables  is  not  appropriate  for  all  compliant  systems  (e.g.,  a 
mechaiusm  on  a  compliant  base). 
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3.  COMPLIANT  MECHANISM  INVERSE  DYNAMIC  EQUATIONS 

3.1  Mechanisms  Modeled  Without  Constraint  Equations 

The  equations  of  motion  (before  substitution  of  specified  joint 
trajectories)  for  open-chain  and  closed-chain  mechanisms  (rigid  or 
compliant),  where  motions  are  defined  in  terms  of  an  independent  set 
of  generalized  coordinates  (q),  have  the  following  form, 

M(q)q  =  f(q,q,t) 

Substitution  of  joint  trajectories  into  the  equations  of  motion  for  a  non- 
compliant  mechanism  results  in  straightforward  evaluation  of  joint 
forces.  Alternately,  substitution  of  trajectories  into  the  equations  of 
motion  for  a  compliant  mechanism  and  conversion  to  standard  form 
(discussed  in  Section  4)  results  in  a  coupled  set  of  first  order 
(Ufferential  and  algebraic  equations  (DAE's). 


K + •"!  +  "hJ  it, = icxj + o; 


x^  =  x, 


F,(x.x.y.t)  =  0 


mp  +  m,  +  +  ^ 


0  =  -^ - )F,(x.y.t)=0 


0 _ 

n^  +  ro,  +  inj  +  mj^y3  < 


The  planar  manipulator  on  a  vertically  compliant  base  shown  in 
Hgure  1  is  used  to  illustrate  formulation  of  an  inverse  dynamic  model 
for  conqiliant  mechanisms  modeled  without  constraint  equations.  The 
planar  mechanism  has  the  d^amic  equations  shown  in  Figure  2  after 
substitution  of  joint  trajectories  (all  joints  must  be  powered  to  produce 
a  controlled  motion)  and  conversion  to  state  space  form.  Gaussian 
elimination  of  derivative  terms  from  the  joint  variable  equations  results 
in  the  standard  form  equations  shown  in  Figure  3  where  the  differential 
equations  correspond  to  the  vertical  deflection  variable  and  the 
algebraic  equations  correspond  to  the  joint  variables.  The  joint  variable 
dynanic  equations  always  reduce  to  algebraic  equations  while  the 
deflection  variable  equations  remain  as  differential  equations  for  any 
compliant  mechanism  modeled  without  constraint  equations. 


Fig.  1  Planar  Manipulator  on  a  Vertically  Compliant  Base 


Xj.X, 

+  "SlrCBj  ♦  x,  -  y^  +  o, 

where:  x,  -  5,.  x,  -  6,.  y,  -  F, ,  y,  -  tj.  y,  - 1, 
a|.  dj,  (I3,  -  constants 

Fig.  2  Dynamic  Equations  in  State  Space  Form  for  a  Planar 
Manipulator  on  a  Vertically  Compliant  Base 


where;  a*.  cC.  o^,  a*  -  modified  constants 

Fig.  3  Dynamic  Equations  in  Standard  DAE  Form  for  a  Planar 
Manipulator  on  a  Vertically  Compliant  Base 


Inverse  dynamic  solutions  for  compliant  mechanisms  modeled 
without  constraint  equations  are  calculated  by  first  integrating  the 
differential  equations  for  the  mechanism  deflections.  The  solved 
deflections  are  then  substituted  into  the  algebraic  equations  to  obtain  the 
joint  forces  required  to  produce  the  desired  motions.  The  two  part 
solution  is  possible  because  the  differential  equations  are  decoupled 
from  the  algebraic  equations  (i.e.,  independent  of  the  joint  forces)  as 
shown  in  Figure  3. 

3.2  Mechanisms  Modeled  With  Constraint  Eouations 

The  equations  of  motion  (before  substitution  of  specified  joint 
trajectories)  for  closed-chain  mechanisms  have  the  following  form 

M(q)q  =  f(q.q,i)  +  G(q)X 

<t>(q)  =  0 

where  =  G^ 

dq 

X  -  Lagrange  multipliers 
0(q)  •  constraint  equations 

The  closed  kinematic  chains  arc  enforced  with  algebraic  constraint 
equations  and  Lagrange  multipliers  in  the  above  equations. 

For  non-compliant  mechanisms,  the  constraint  equations  are 
identically  satisfied  by  the  si^ified  jmnt  trajectories  so  these  equations 
provide  no  useful  information  for  the  inverse  dynamic  model.  The 
number  of  unknowns  (joint  and  constraint  forces)  may  exceed  the 
number  of  available  dynamic  equations  for  inverse  dynamic  models  of 
closed-chain,  non-compliant  systems.  This  occurs  when  the  number 
of  actuated  joints  is  greater  than  the  number  of  system  dofs.  In  such 
cases,  an  infinite  number  of  possible  force  solutions  exist  for  a  given 
trajectory.  Many  of  the  possible  solutions  correspond  to  actuator 
conflia  where  powoed  joints  act  in  an  isometric  (i.e.,  non-productive) 
manner.  An  example  of  actuator  conflict  is  shown  in  Figure  4  for  a 
non-compliant  four  bar  linkage. 


Fig.  4  An  Example  of  Actuator  (Conflict  for  a  Non-Compliant,  Four 
Bar  Linkage 
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Wh»  a  closed-chain  mechanism  has  compliance  in  each  closed 
kinematic  chain,  the  inverse  dynamic  solution  is  detenninate  for  any 
number  of  actuated  joints  because  opposing  actuator  forces  result  in 
defonnadon  that  distributes  internal  forces.  The  compliance  must  be 
atranged  so  that  no  mechanism  morion  is  rigidly  constrained  for  the 
problem  to  be  determinate.  Otherwise,  the  degree  of  indeterminacy 
would  be  reduced  and  not  eliminated  dependent  on  the  number  of 
constraint  equations  that  are  no  longer  applicable.  When  sufficient 
system  compliance  exists  for  the  inverse  dynamic  solution  to  be 
detenninate  considering  all  joints  to  be  actuated,  the  mechanism  will  be 
lefened  to  as  fiilly  compliant. 


p,j  +  *3^0,  “  *3^0, 

Py,  ®o,  'll,  +  *  Py^  +  +  d,^  +  IjSBj^  +  IjSGjj^ 

where:  (p,^,  Py^),  (p^,  Py^)  -  manipulator  base  positions 


All  joints  in  a  closed-chain  mechanism  do  not  have  to  be  powered  to 
produce  a  controlled  mechanism  morion.  The  existence  of  a 
detenninate,  inverse  dynamic  solution  for  a  less  than  fully  compliant, 
closed-chain  mechanism  is  dependent  on  having  an  unactuated  joint 
with  a  spewed  trajectory  in  each  closed  Idneraaric  chain  corresponding 
to  an  eliminated  constraint  equation.  (Ginsiraint  equations  cannot  be 
eliminated  for  fully  compliant,  clos^-chain  mechanisms  because 
deflection  variables  are  present  in  these  equations.)  If  a  joint  it 
nnpowered  (i.e.,  its  trajectory  is  unknown)  in  a  fully  compliant, 
closed-chain  mechaiusm,  the  corresponding  joint  rtwrion  is  governed 
by  the  deflection  variables  in  addition  to  the  constraint  equations. 
Either  a  trajectory  or  force,  but  not  both,  is  specified  for  each  joint  of  a 
fully  compliant,  closed-chain  mechanism  because  the  unknown 
deflection  variables  and  constraint  forces  affect  the  unspecified 
quantity. 

The  inverse  dynamic  timdel  of  a  compliant  mechanism  modeled 
with  constraint  equations  is  obtained  by  sub^tution  of  die  defined  joint 
trajectories  into  the  equations  of  motion  for  the  system;  conversion  of 
the  equations  to  standard  form  results  in  a  coupled  set  of  DAPs.  An 
example  of  two  rigidly  connected,  planar  manipulators  on  independent, 
vertically  compliant  bases  shown  in  Figure  5  is  used  to  illustrate 
formulation  of  an  inverse  dynamic  model  for  compliant  mechanisms 
modeled  with  constraint  equations.  The  constraint  equations  given  in 
Hgure  6  ensure  compatability  at  the  end-effeaors.  Joints  du.  Bn  and 
032  were  considered  to  be  powered  which  results  in  a  determinate 
solution.  (If,  in  addition,  joints  621  and  Bsi  were  considered  to  be 
powered,  the  lint  and  third  constraint  equations  would  be  eliminated 
and  the  inverse  dynamic  solution  would  b«x>nie  indeterminate.) 


Rg.  3  Two  Rigidly  Connected,  Planar  Manipulaton  on  Independent, 
Vertically  Compliant  Bases 


Hg.6  Constraint  Equations  for  Two  Rigidly  Connected,  Planar 
Manipulators  on  Independent,  Vertically  Compliant 


The  inverse  dynamic  equations  have  the  functional  form  shown  in 
Rgure  7  after  substitution  of  the  joint  trajectories  and  conversion  to 
state  space  form.  Gaussian  eliminarion  of  derivative  terms  from  the 
dynamic  equarions  for  joint  variables  having  defined  trajectories  (Le., 
<li2>  022  a&d  032)  results  in  the  standard  form  equarions  shown  in 
Rgme  8.  The  differential  equarions  correspond  to  rif-fleciion  and  joint 
variables  having  unspecifled  morions  while  the  algebraic  equarions 
correspond  to  constraint  equations  and  joint  variables  with  specified 
trajectories. 

M  j’x  j  »  A(x,y)  +  B 


where:  B  -  constant  vector 
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Rg.  7  Dynamic  Equations  in  State  Space  Form  for  Two  Rigidly 
Connected,  Planar  Manipulators  on  Independent,  Vertically 
(jompliant  Bases 
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The  dynamic  equations  for  joint  variaUes  having  defined  trajectories 
reduce  to  algebraic  equations  whil»the  constraint  equations  remain  as 
algebraic  equations  for  any  compliant  mechanism  modeled  with 
constraint  equations.  Also,  the  dynamic  equadons  for  joint  and 
deflection  variables  having  unspecified  motions  remain  as  differential 
equations.  The  difference  between  inverse  dynamic  models  for 
systems  modeled  with  and  without  constraint  equations  is  the 
additional  algebraic  (constraint)  equations  of  the  former.  These 
additional  equations  serve  to  couple  the  differential  and  algebraic 
equations  of  the  inverse  dynamic  model  through  the  Lagrange 
multipliers;  this  eliminates  the  possibili^  of  separate  solutions  (as  for 
systems  modeled  without  constraint  equations).  Relevant 
characteristics  of  DAE  systems  are  considered  below  so  that 
appropriate  solution  techniques  can  be  defined  for  inverse  dynamic 
models  of  compliant  mechanisms  modeled  with  constraint  equations. 

4.  DIFFERENTTAL/ALGEBRAIC  EQUATIONS 


1 


A(x.y) « 


A  coupled  set  of  DAE's,  which  are  also  described  as  singular 
systems  of  differential  equations  [McClamtoch  86],  can  be  exprused 
in  the  following  standard  form 

F,(x,x,y,t) »  0 


t 

Fll 

tn  •  •  X, 

•  •  X, 


where:  *•  indicates  a  non*zen>  entry 

7  (corn'd)  Dynamic  Equations  in  State  Space  Form  for  Two 
Rigidly  Connected,  Planar  Manipulators  on  Inttependent,  Vertically 
Compliant  Bases 


Fj(x.y,t).0 

Systems  of  DAE's  cannot  be  solved  directly  using  numerical 
methods  intended  for  ordinary  differential  equations  (ODE's);  an 
equation  transformation  or  special  numerical  techniques  must  be 
considered.  A  singularity  measure  of  a  set  of  DAE's  is  given  by  its 
index  (or  nilpotency)  and  the  solution  difficulty  increases  as  the  index 
increases  [Petzold  82].  The  index  of  a  system  is  determined 
transfonning  the  set  td*  equations  into  canonic^  form  and  observing  the 
size  of  the  coefficient  matrix  for  the  non-state  variables  (i.e.,  variables 
not  having  any  derivative  terms).  An  alternate  approach  for 
determining  the  index  [Gear  88]  is  to  count  the  required  number  of 
differentiations  of  the  algebraic  equations  to  produce  a  set  of  ODE's. 
The  fmward  dynamic  mii^l  of  a  closed-chain  mechanism  is  shown 
(Petzold  86]  to  be  index  3  or  index  2  when  position  or  velocity 
constraints  ate  defined,  respectively. 


Fi(xi,y,t)  »  0 
F2(x,y,t) »  0 

where:  F](x  jc,y,t)  -  same  as  first  10  equations  of  Figure  7 


Solutions  to  determinate  systems  of  DAE's  can  be  obtained 
substituting  backward  difference  formulas  (BDF)  for  the  derivative 
expressions  and  solving  the  resulting  set  of  simultaneous  equations 
iteratively  using  Newton's  method  [Gear  71).  (There  are  no  proven 
optimzation  techniques  for  indeterminate  DAE  systems  except  for  the 
prelimin^  work  in  [Lotstedt  84].)  For  a  genei^  system  of  DAE's, 
the  Jacobian  matrix  used  in  Newton's  method  is 
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where  h  -  stepsize 
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Hg.  8  Dynamic  Equations  in  Staixlard  DAE  Form  for  Two  Rigidly 
Conneend,  Phuiar  Manipulators  on  Independent,  Vertically 
Compliant  Bases 


A  unique  solution  exists  if  the  Jacobian  is  non-singular.  An 
obvious  requirement  for  an  invertible  Jacobian  is  that  dFj/dy  be  non¬ 
singular.  which  is  an  alternate  definition  of  an  index  1  system  [Lotstedt 
86).  For  this  reason,  index  I  DAE  systems  can  be  readily  solved  using 
BDF  substitution  and  Newton's  method  with  little  more  difficulty  than 
solving  ODE's.  A  mathematically  precise  requirement  for  a  unique 
solution  to  exist  is  that  the  Schur  complement  [Cottle  74]  of  the  above 
matrix  must  be  non-singular.  This  explains  why  solutions  can  be 
obtained  for  certain  higher  order  systems  (i.e.,  index  greater  than  1) 
where  dF2/dy  is  singular.  A  solvable  index  2  system  has  non-zero 
tows  of  dFj/dy  that  are  linearly  independent  [Lotstedt  86). 
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The  emr  in  solving  index  1  systems,  solvsble  index  2  systems  and 
index  3  mechanical  systems  of  DAB'S  using  a  «<«««"»  stepsize  BDF  is 
0(h^)  [Locstedt  86],  where  k  is  the  ofder  ^  the  difference  expression 
and  h  is  the  stepsize.  The  use  of  variable  stepsizes  is  difficult  because 
the  nonnal  emr  definitions  used  for  DDEs  can  be  completdy  inconrect 
for  DAB'S  as  a  result  of  the  ncm-state  vaiiable  contributions.  A  suii^le 
enor  definition  used  for  variable  stepsize  control  of  DAE  systems  is 
discussed  in  [Petzold  82]. 

A  method  for  reducing  the  index  of  a  set  of  DAE's  [Gear  88]  is  to 
differentiate  the  consoaint  equations  to  produce  a  DAE  system  with  an 
index  that  is  one  lower  for  e^  differentiation.  Taken  to  the  extreme, 
this  approach  can  result  in  a  system  of  DDEs.  Since  the  ODE  system  is 
equivalent  to  the  original  DAE  system,  calculated  solutions  will  depead 
on  dffferentials  of  sute  vari^les,  non-state  variables  and  input 
functions;  any  discontinuities  in  the  latter  can  result  in  non-defined 
solutioi^  Similariy,  consistent  initial  conditions  that  satisfy  not  only  the 
constraint  equations  but  derivatives  of  the  constraint  equations  are 
essential;  otherwise,  errots  in  the  initial  conditions  will  contaminate  the 
solution. 

5.  EQUATION  INDEX  OF  COMPLIANT  MECHANISM  INVERSE 
DYNAMIC  MODELS 


original  variables 
state  space  variables 

Fi2  t22  t32  Xi 

•yi  yz  n  y* 
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ys 
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3F2/3y  ■ 


where:  *  -  indicates  a  non-zero  entry 


The  inverse  dynamic  equations  of  motion  for  a  compliant 
mechanism  modeled  without  consoaint  equations  have  been  shown  by 
this  study  to  be  a  set  of  DAE's  where  the  differential  equations 
oocreqxmd  to  unknown  deflection  variables  and  the  algebnic  equations 
oofreq>ood  to  unknown  joint  forces.  Converting  the  equations  to 
standard  form  results  in  an  index  1  system  because  dF^^y  is  non¬ 
singular.  A  single  unknown  joint  force  is  unique  to  each  algebraic 
equation  which  makes  the  rows  of  dFj/dy  always  linearly  indepmdent 
as  shown  by  the  example  equations  for  the  pl«nar  nuuiipulatar  on  a 
vertically  compliant  base  given  in  Hgure  9. 


9F2/9y  •• 
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lag.  9  dFydy  for  a  Planar  Manipulator  on  a  Vertically  Compliant  Base 


Hg.  10  dP^ldy  for  Two  Rigidly  Connected,  Planar  Manipulators  on 
Independent,  Vertically  Compliant  Bases 


5.  SUMMARY 

A  general  formulation  of  inverse  dynamic  models  for  all  compliant 
mrchanisms  is  presented  where  the  oaodel  is  obtained  by  substitution 
of  prescribed  joint  motions  into  the  eqtuirions  of  motion  for  the  systeno. 
The  resulting  equations  for  compliant  mechanisms  modeled  with  and 
without  constraint  equations  are  shown  to  be  solvable  index  2  and 
index  1  DAE  systems,  respectively.  Relevant  characteristics  of  DAE 
systems  and  solutions  of  these  equations  are  rfitQKwt  Stable  and 
aoctnte  numerical  solutions  can  be  obtained  by  BDF  substitution  and 
application  of  Newton's  method  to  the  resulting  set  of  equations. 

'Die  formulation  and  solution  procedures  have  been  used  to  define 
the  inverse  dynanuc  model  of  legged  locomotion  on  natural  terrain. 
Foot-soil  interactions  are  modeled  with  non-linear  force-deflection 
relationships  resulting  in  a  fully  compliant  model  and  determinate 
solutions.  The  mechanism  structure  and  joints  are  considered  to  be 
rigid  while  joint  damping  and  backdrive  effects  are  included  in  the 
naod^  Stable  solutions  are  being  calculated  with  two  to  five  Newton 
iterations  per  timestep.  The  locomotion  model  is  currently  being  used 
for  gait  and  control  system  simulation  studies  of  a  multi-legged  robot 
under  development  at  the  Field  Robotics  Center,  Carnegie  Mellon 
University. 


If  the  mechanism  has  closed  kinematic  chains  modeled  with 
constraint  equations,  additional  algebraic  equations  and  non-state 
variables  corresponding  to  the  constraint  equations  and  Lagrange 
multipliers,  respectively,  are  included  in  the  equations  of  motion. 
These  additional  equations  make  singular  bmuse  the  constraint 

equations  are  independent  of  the  non-state  variables  (Le.,  variables  not 
having  derivative  terms  in  the  equations).  The  non-zero  rows  of 
dpydy  are  always  linearly  independent  because  a  single  unknown  joint 
foree  is  uiraue  to  each  al^faraic  equation  that  corresponds  to  joints 
with  specified  trajectories  (i.e.,  actuated  joinu).  This  linear 
indraendence  is  shown  by  the  ^uations  given  in  Figure  10  for  two 
rigimy  connected,  planar  manipulators  on  independent,  vertically 
compliant  bases.  Therefore,  the  inverse  dynamic  equations  of  motion 
for  a  compliant,  closed-chain  mechanism  modeled  with  constraint 
equations  are  a  solvable  set  of  index  2  DAEs. 
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Abstract 

To  perform  planetary  exploration  witlwut  human  supervision, 
a  complete  autonomous  robot  must  be  able  to  model  its  environ¬ 
ment  and  to  locate  itself  while  exploring  its  surroundings.  For 
that  purpose,  we  propose  a  modular  perception  system  for  an  au¬ 
tonomous  explorer.  The  percq>tion  system  maintaitu  a  consistent 
internal  representation  of  the  observed  terrain  from  multiple  sen¬ 
sor  views.  The  representation  can  be  accessed  frtmi  other  modules 
through  queries.  The  perception  system  is  intended  to  be  used  by 
the  Ambler,  a  six-legged  vehicle  being  built  at  CMU.  A  partial  im¬ 
plementation  of  the  system  using  a  range  scanner  is  presented  as 
well  as  experimental  results  on  a  testbed  that  includes  the  sensor, 
one  computer  controlled  leg,  and  obstacles  on  a  sandy  surface. 

1  Introduction 

The  unmanned  exploration  of  planett,  such  as  Man,  requires  a 
high  level  of  autonomy  due  to  the  communication  delays  between 
a  robot  and  the  Earth-based  station.  This  impacts  all  the  compo¬ 
nents  of  the  system;  planning,  sensing,  and  mechanism  [6].  In 
particular,  such  a  level  of  autonomy  can  be  achieved  only  if  the 
robot  has  a  perception  system  that  can  reliably  build  and  maintain 
models  of  the  environment  We  propose  a  perception  system  that  is 
designed  for  application  to  autonomous  planetary  exploration.  The 
perception  system  is  a  major  part  of  the  development  of  a  com¬ 
plete  system  that  includes  planning  and  mechanism  design.  The 
target  vehicle  is  the  Ambler,  a  six-legged  walking  maciiine  being 
developed  at  CMU  (Figure  1.  [1]). 

The  perception  system  can  be  viewed  as  an  intelligent  mem¬ 
ory  that  can  be  interrogated  by  external  modules  (e.g.,  path  plan¬ 
ning  modules)  while  maintaining  an  internal  r^esentadon  of  the 
world  built  from  sensors  as  the  vehicle  navigates.  The  paper  ad¬ 
dresses  the  choice  of  the  basic  representation  maintained  by  the 
system  in  Section  2  and  the  architecture  of  the  perception  system 
in  Section  3.  Although  the  arc:j*:cture  is  designed  to  handle  a 
variety  of  sensors,  we  have  focused  on  the  use  of  a  laser  range 
finder,  since  the  first  requirement  for  safe  navigation  of  the  robot 
is  reliably  modeling  the  geometry  of  the  surrounding  terrain.  Sec¬ 
tion  4  describes  the  algorithms  developed  for  the  construction  of 
terrain  models  from  range  images.  Finally,  Section  5  describes  the 
experiments  that  were  conducted  to  evaluate  the  perception  system. 
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2  Terrain  Representation 

The  basic  internal  representation  used  by  the  perception  system  is  a 
grid,  the  local  terrain  map.  each  cell  of  which  contains  attributes  of 
the  terrain.  A  cell  must  contain  at  least  the  elevation  of  the  tenain 
and  the  uncertainty  on  the  elevation  due  to  sensor  noise.  The 
uncertainty  is  modeled  u  a  Gaussian  distribution,  whose  standard 
deviation  <t  is  stored  in  the  teirain  map.  Other  attributes  may 
include  the  slope,  the  surface  texture,  etc.  In  addition,  attributes 
that  are  stared  in  a  cell  may  be  of  non-geometric  nature,  such  as 
the  color  of  the  terrain.  Several  resolutions  of  the  grid  may  be 
maintained  simultaneously. 

On  top  of  the  base  grid,  higher  level  information  can  be  rep¬ 
resented  in  the  form  of  labeled  features  in  the  grid,  such  as  to¬ 
pographic  features  (hills,  ravines,  etc.X  regions  of  homogeneous 
terrain  type,  objects  of  interest  that  have  been  extracted  (boulders, 
rocks,  etc.). 

Other  terrain  representations  are  possible.  The  surface  could 
be  represented  directly  by  3-D  patches  that  either  are  approxima¬ 
tions  of  the  measured  surface  or  are  built  directly  upon  the  set  of 
dau  points.  In  both  cases,  however,  retrieving  a  region  of  interest 
from  the  map  becomes  a  complex  operation.  Another  possibility 


20 


is  to  represent  only  a  higher-level  description  of  the  tenain,  such 
as  a  segmentation  of  the  sniface.  This  is  not  appropriate  in  our 
case  since  some  planning  tasks  need  information  at  the  lowest  level 
(elevation  map).  One  example  for  the  Ambler  is  to  estimate  how 
stable  a  foot  placement  on  the  terrain  would  be.  in  that  case  a 
surface  description  at  a  resolution  that  is  well  below  the  size  of 
the  foot  is  needed.  By  contrast  with  the  alternative  represenu- 
tions.  the  terrain  m^  tepresenution  as  an  elevation  mq>  is  simple 
to  manipulate,  can  include  high-level  information  as  well  as  high 
resolution  elevation  data,  and  can  be  accessed  by  external  modules 
in  a  simple  way  by  giving  the  boundary  of  the  region  of  interest 
in  the  map. 

3  Architecture 

The  perception  system  is  divided  into  six  logical  modules  (Fig.  2). 
The  system  communicates  with  external  modules  using  messages 
that  are  routed  through  a  central  message  handler  [4].  The  percep¬ 
tion  system  is  controlled  by  a  front  end — the  Local  Temin  Map 
Manager  (LTMM) — that  receives  the  messages.  Once  a  message 
requesting  data  is  received,  the  LTMM  checks  whether  it  is  avail¬ 
able  in  the  current  internal  terrain  map.  If  not,  then  the  LTMM 
instructs  the  Imaging  Sensor  Manager  (ISM)  to  take  a  new  image 
from  the  relevant  sensors,  and  the  terrain  map  from  the  new  image 
is  merged  in  the  current  terrain  map.  The  internal  representation 
is  a  terrain  map  built  with  respect  to  a  fixed  reference  frame,  the 
global  frame  Q.  All  the  operations  in  the  overall  Ambler  system 
are  expressed  with  respect  to  0.  A  separate  module  provides  the 
vehicle  pose  in  Q.  Since  the  terrain  map  is  of  interest  only  in 
a  region  around  the  vehicle,  useless  paru  of  the  terrain  map  are 
discarded  by  another  module,  the  Scroller. 


Figure  2:  Architecture  of  the  perception  system 


3.1  Accessing  the  Perception  System 

External  modulea  communicate  with  the  perception  system  by  ex¬ 
changing  messages  (Rg.  2).  Two  types  of  messages  are  used; 
queries  that  are  request  for  data,  and  replies  that  are  used  for  send¬ 
ing  data  in  response  to  a  query.  The  queries  and  replies  are  routed 
and  synchronized  by  a  central  module  [4].  The  simplest  exam¬ 
ple  of  a  query  from  a  planning  module  would  be  a  request  for  an 
elevation  map  in  a  given  area  for  clearance  checking.  The  main 
advamage  of  this  mode  of  access  is  that  external  modules  do  not 


need  to  know  the  internal  workings  of  the  percq>tion  system  such 
as  the  sensor  used  or  the  format  of  the  internal  representation. 

The  LTMM  is  the  front  end  to  the  perception  system,  and 
is  responsible  for  processing  queries  and  for  activating  the  proper 
submodules.  When  a  query  is  received,  the  manager  first  checks 
if  the  area  of  interest  has  been  already  processed  at  the  requested 
resolution,  if  that  is  the  case  the  requested  information  is  extracted 
from  the  existing  terrain  m^),  otherwise  the  manager  requests  a 
new  image  from  the  ISM  that  is  processed  and  merged  with  the 
current  terrain  map. 

To  be  processed  all  queries  must  contain  three  pieces  of  in¬ 
formation:  a  polygon  that  is  the  boundary  of  the  region  of  interest; 
a  resolution  that  indicates  at  what  level  of  detail  the  requested  cal¬ 
culations  must  be  carried  out  on  the  terrain  map;^  and  the  type 
of  information  requested  (elevation,  uncertainty,  slopes,  etc.).  Be¬ 
cause  all  queries  are  expressed  in  G,  external  modules  do  not  need 
to  know  the  pose  of  the  sensors.  The  transformation  between  a 
sensor  and  the  vehicle's  base  frame  is  stored  internally  by  the  per¬ 
ception  system,  while  the  current  vehicle  pose  with  respect  to  $  is 
requested  each  time  a  query  is  received. 

3.2  Acquiring  Sensor  Data 

Instead  of  hardcoding  the  sensor  interface  into  the  LTMM,  sensor 
dtia  is  obtained  through  the  same  query  mechanism.  Whenever 
an  image  is  requested,  the  requesting  module  sends  a  query  to  the 
ISM  that  includes  the  type  of  sensor  and  the  type  of  data  desired. 
The  ISM  is  responsible  for  activating  the  requested  sensor.  The 
ISM  can  be  viewed  as  a  virtual  sensor  that  hides  the  details  of  the 
senson*  interfaces  firom  the  perception  system,  thus  allowing  for  a 
more  flexible  way  of  changing  sensor  specifications.  Because  all 
queries  are  expressed  in  G,  the  ISM  is  also  responsible  for  request¬ 
ing  the  position  of  the  vehicle  with  respect  to  G  from  a  module 
that  keeps  track  of  the  position  of  the  robot  either  by  dead  reck¬ 
oning  or  by  using  a  navigation  system.  The  other  transformation 
that  is  needed  in  order  to  use  the  sensor  data  is  the  transformation 
between  sensor  frame  and  vehicle  frame;  this  transformation  is 
pre-computed  by  a  calibration  procedure  and  stored  by  the  ISM  at 
initialization  time.  The  composition  of  those  two  transformations, 
that  is  the  transformation  between  sensor  frame  and  G,  is  returned 
to  the  perception  system  along  with  the  sensor  data  (Fig.  3). 


Figure  3;  The  Imaging  Sensor  Manager 


*For  example,  a  resolution  of  leveral  tent  of  cemimeten  it  tuffident 
for  checking  that  the  path  of  the  body  it  clear.  Analyzing  the  tubility  of 
one  foot  of  the  Ambler  requires  s  resolution  of  s  few  cemimeten. 
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33  Building  the  Terrain  Map 

Once  a  query  is  received,  a  terrain  map  must  be  built  within  the 
boundary  of  the  region  of  interest  This  is  the  role  of  the  Builder 
(Fig.  2)  which  constructs  a  terrain  map  given  sensor  dau  taken  at 
one  position  of  the  vehicle.  The  terrain  map  is  computed  at  the 
requested  resolution  and  includes  the  elevation  and  the  unceitainty 
at  each  point  In  addition  to  those  two  attributes,  the  Builder  also 
implements  the  algorithms  for  computing  other  local  attributes  such 
as  slope  or  surface  texture  as  well  as  non-geometric  attributes  such 
as  color  or  terrain  type  depending  on  the  available  sensors.  In 
addition  to  computing  the  local  attributes,  the  Builder  also  identifies 
the  portions  of  the  m^  that  axe  outside  of  the  fields  of  view  of  the 
sensors,  and  those  that  ate  occluded  by  parts  of  the  terrain. 

The  Builder  is  optimized  in  several  ways:  It  maintains  maps 
at  different  resolutions  so  that  it  is  not  necessary  to  always  com¬ 
pute  the  map  at  finest  resolution.  Also,  if  a  map  at  the  desired 
resolution  does  not  exist,  the  Builder  will  create  one,  thus  allow¬ 
ing  for  arbitrary  resolutions.  The  Builder  minimizes  the  amount 
of  computation  by  remembering  both  the  regions  of  the  world  that 
have  already  been  computed  and  by  storing  the  past  images  so  that 
if  a  query  falls  within  the  field  of  view  of  an  existing  image,  it  is 
not  necessary  to  acquire  and  process  a  new  image. 

An  implementation  of  a  Builder  that  uses  range  images  is 
described  in  Section  4. 

3.4  Updating  the  Terrain  Map 

Since  the  Builder  constructs  a  terrain  map  from  a  single  image, 
new  sensor  data  has  to  be  acquired  each  time  a  new  query  is  re¬ 
ceived.  This  is  sufficient  as  a  fint  approximation,  however  the 
perception  system  should  be  able  to  han^e  terrain  maps  built  from 
sensor  dau  acquired  at  different  positions.  There  are  two  motiva¬ 
tions  for  handling  multiple  frames.  It  is  obviously  more  efficient 
to  remember  terrain  mqrs  built  from  previous  frames  rather  than 
recomputing  everything  at  each  step.  A  more  compelling  moti¬ 
vation  is  that  merging  multiple  frames  may  be  the  only  way  to 
provide  the  requested  data.  Such  a  situation  occurs  when  parts  of 
the  vehicle,  usually  a  leg,  lie  within  the  field  of  view  of  the  sensor 
and  therefore  occludes  a  part  of  the  terrain  map,  in  that  case  it  may 
not  be  possible  to  extract  the  region  of  interest  from  the  current 
position.  A  second  case  in  which  multiple  frames  are  needed  is 
when  dau  that  is  outside  of  the  current  field  of  view  of  the  sensor 
is  needed.  In  the  case  of  the  Ambler,  this  is  actually  the  standard 
situation  since,  in  the  normal  walking  mode,  the  leg  further  behind 
the  body  is  moved  to  the  front  of  the  body  which  requires  dau 
behind  the  body  so  that  the  path  of  the  leg  can  be  checked  for 
clearance.  For  these  reasons,  the  perception  system  must  include 
the  curability  to  merge  terrain  maps  frtwn  successive  frames  into  a 
single  terrain  map. 

The  responsibility  for  the  management  of  multiple  terrain 
maps  is  shared  by  two  modules,  the  Matcher  and  the  Merger 
(Fig.  2).  The  Matcher  estimates  the  displacement  between  a  new 
terrain  map  and  the  current  interrud  terrain  map.  The  displacement 
is  in  general  a  3-D  traruformation.  It  is  estimated  by  matching  fea¬ 
tures  extracted  from  the  maps,  or  by  using  a  correlation  technique 
that  compares  the  two  maps  directly.  Section  4  briefly  describes  an 
implementation  of  the  latter  in  the  case  of  terrain  maps  built  from 
range  images.  An  initial  estimau  of  the  displacement  is  always 
available  either  from  deed  reckoning  or  from  a  navigation  system. 
Once  the  displacement  is  computed,  the  Merger  is  responsible  for 
merging  the  new  map  into  the  current  map.  Actually,  only  the 
part  of  the  map  that  it  within  the  requested  region  of  interest  is 


actually  merged  for  efficiency  reasons.  The  maps  are  merged  by 
combining  the  elevation  values  at  each  location  of  the  map  using 
the  uncertainty  values  to  obtain  the  maximum  likelihood  estimate 
of  the  elevation.  The  Merger  must  also  updau  the  occluded  areas 
of  the  current  map. 

It  is  important  to  logically  separate  the  matching  and  merg¬ 
ing  operations.  First  of  all,  the  matching  operation  may  or  may 
not  be  necessary  depending  on  the  accuracy  of  the  positioning  sys¬ 
tem.  If  a  navigation  system  provides  displacement  estimates  that 
are  well  below  the  resolution  of  the  grids,  the  estimates  will  not 
be  improved  by  terrain  matching.  Second,  if  raw  sensor  dau  is 
stored  along  with  past  terrain  maps,  a  new  query  requires  only 
merging  portions  of  the  terrain  maps  since  the  displacemenu  have 
already  been  computed  at  the  time  the  images  were  acquired.  Fi¬ 
nally,  separating  the  two  modules  allows  for  experimenting  with 
different  matching  algorithnu,  presumably  the  most  difficult  part 
of  the  system,  while  retaining  the  same  structure  for  the  rest  of  the 
system. 

Since  the  terrain  map  must  grow  as  the  vehicle  moves  and 
as  new  sensor  dau  is  acquired,  a  third  module,  the  Scroller,  is 
responsible  for  discarding  the  part  of  the  map  that  is  too  far  from 
the  vehicle  to  be  useful  This  can  be  viewed  as  sliding  a  window 
centered  on  the  current  position  of  the  vehicle;  only  dau  within 
this  window  is  retained.  The  Scroller  is  motivated  both  by  the  need 
to  prevent  the  size  of  the  terrain  map  from  expanding  during  the 
course  of  a  long  mission,  with  the  risk  of  memory  overflow,  and 
by  the  fact  that  only  the  most  recent  terrain  maps  can  be  used  with 
confidence  due  to  the  accumulation  of  errors  in  the  displacement 
estimates  between  mqps. 

4  Elevation  Maps  from  Range  Data 

The  perception  system  is  designed  to  use  multiple  sources  of  data. 
Because  geometric  information  is  most  important  for  local  naviga¬ 
tion,  we  consider  in  this  section  the  case  of  dau  from  an  active 
range  scanner. 

We  use  the  Erim  laser  scanner,  which  deliven  64  x  2S6  range 
images  by  measuring  the  phase  difference  between  a  laser  beam 
aixi  its  reflection  from  a  point  in  the  scene  [7],  The  scarmer  mea¬ 
sures  the  range  p  in  a  spherical  coordinate  system  in  which  4>  and 
are  the  vertical  and  horizontal  scarming  angles,  corresponding  to 
tow  atxl  column  positioiu  in  the  image. 

Prior  to  operation,  the  position  of  the  sensor  with  respect  to 
the  vehicle’s  coordinate  frame  must  be  computed.  This  is  done 
by  a  calibration  procedure  that  computes  the  position  by  observing 
markings  on  the  leg  using  the  range  scanner  at  different  known 
positions  of  the  leg.  A  least-squares  estimation  algorithm  estimates 
the  traruformation  between  the  coordinate  system  of  the  scanner 
and  the  coordinate  system  of  the  vehicle.  This  traruformation  is 
compounded  with  the  traruformation  between  vehicle  and  global 
frames  by  the  ISM  each  time  a  new  image  is  acquired. 

The  easiest  way  to  convert  the  range  images  to  elevations 
maps  is  to  convert  each  pixel  (p,  9,  to  a  point  in  space  (x,  y,  z), 
which  is  straightforward  ktwwing  the  geometry  of  the  sensor  and 
the  transformation  between  sensor  and  global  frames.  This  ap¬ 
proach  has  some  severe  drawbacks,  however,  such  as  the  need  for 
interpolation,  the  dependency  on  a  particular  coordinate  system, 
and  the  fact  that  it  is  not  possible  to  limit  the  compuution  to  a  re¬ 
gion  of  the  terrain  map  because  we  do  not  know  apriori  where  this 
region  is  in  the  image.  Itutead,  we  use  the  locus  method  described 
in  [3].  This  approach  has  many  advantages  including  the  explicit 
detection  of  range  shadows,  the  representation  of  uncertainty,  the 
independence  of  the  algorithm  with  respect  to  a  reference  frame. 
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t  stnightforwaid  extouion  lo  the  case  of  multiple  frames  of  data. 
Furthermore,  a  major  feature  of  the  locus  method  is  its  ability  to 
limit  the  computation  of  the  lenain  map  to  any  region  in  space, 
thus  facilitating  the  computation  of  the  maps  within  the  boundaries 
of  the  queries  of  Section  3.1. 

The  terrain  map  building  algorithms  were  evaluated  on  range 
images  taken  by  the  Erim  scanner.  The  test  images  were  taken  in 
a  construction  site  that  exhibits  the  type  of  rugged  terrain  that  we 
are  interested  in.  Fig.  4  shows  a  map  built  from  one  range  image 
using  the  locus  algorithm.  The  resolution  is  10  cm  over  a  10  x  10 
m  square. 


Figure  4;  Elevation  map  built  from  one  range  image 


An  extension  of  the  locus  algorithm  allows  for  matching  and 
merging  terrain  maps  built  from  images  taken  from  different  posi¬ 
tions.  The  matching  algorithm  computes  the  best  3-D  transforma¬ 
tion  between  m^>s,  while  the  merging  algorithm  computes  optimal 
combination  of  the  elevation  from  the  two  maps  given  this  iraiu- 
formation.  The  map  building  from  multiple  frames  was  tested  on 
sequences  of  Erim  images  as  well  as  on  synthesized  images.  Fig.  5 
shows  the  terrain  map  obtained  by  merging  data  from  four  succes¬ 
sive  range  images.  The  resulting  terrain  map  is  about  thirty  meters 
long.  In  this  example  the  images  were  collected  along  a  general 
path  including  a  sharp  turn  (about  30*).  The  matching  between 
consecutive  terrain  maps  was  performed  by  first  matching  features 
to  obtain  a  fint  estimate  of  the  transformation  [3],  and  by  using  the 
estimate  as  a  starting  point  for  the  minimization  of  the  difference 
between  the  two  terrain  maps  that  is  used  as  the  final  transforma¬ 
tion  for  the  merging.  Experiments  on  synthesized  images  for  which 
the  transformation  between  images  is  known  show  that  the  error 
on  the  resulting  transformation  can  be  as  small  as  the  resolution  of 
the  grid.  The  error  in  elevation  is  of  the  order  of  a  few  centimeters, 
increasing  with  the  uncertainly  as  the  points  are  further  away  from 
the  sensor. 

These  experiments  show  that  the  algorithms  developed  for 
range  dau  provide  the  type  of  terrain  maps  required  for  rugged, 
unstructured  environments  including  variable  resolution,  arbitrary 
reference  frame,  explicit  uncertainty  representation,  and  represen¬ 
tation  of  occluded  areas. 


Figure  S:  Elevation  map  from  125  range  images 


5  Experimentation 

A  first  version  of  the  perception  system  of  Fig.  2  is  implemented. 
This  version  includes  the  LTMM,  ITM  Builder,  and  ISM.  This 
implementation  includes  the  algorithms  of  Section  4  and  uses  the 
Erim  scanner.  This  implementation  of  the  system  is  used  to  vali¬ 
date  the  interface  on  single  range  images.  The  system  builds  terrain 
maps  with  currently  two  amibntes:  uncertainty  and  footfall  evalu¬ 
ation.  The  latter  is  a  measure  of  how  good  a  footfall  each  location 
in  the  map  would  be,  based  on  the  local  shape  of  the  terrain.  The 
algorithms  used  for  the  footfall  evaluation  are  described  in  [2]. 
Three  types  of  queries  are  currently  recognized: 

•  Elevation  map:  This  is  a  request  for  an  elevation  map  within 
a  given  region  (polygon)  with  a  given  resolution. 

•  Elevation  and  uncertainty  mq>:  This  is  basically  the  same 
query  except  that  the  uncertainty  at  each  point  of  the  terrain 
map  is  returned  as  welL 

•  Footfall  evaluation:  This  is  a  request  for  the  best  position  of 
the  foot  within  a  region.  Currently  this  request  is  processed 
by  computing  the  stability  of  a  circular  foot  at  each  point  of 
the  terrain  map  by  using  only  the  geometry  of  the  terrain  (2). 

Fig.  6  shows  the  result  of  processing  a  footfall  evaluation 
query.  The  lower  left  view  displays  an  overhead  view  of  the  site 
with  the  region  of  interested  displayed  as  a  shaded  polygon.  The 
three  other  views  are  the  map  computed  from  a  range  image.  The 
lower  right  map  is  a  map  of  the  footfall  evaluation  in  which  the 
highest  values  correspond  to  the  best  footfall  locations.  The  di¬ 
mensions  on  the  lower  left  diagram  are  in  meters.  The  resolution 
of  this  query  is  10  cm. 

A  testbed  was  built  in  order  to  test  the  friUy  integrated  plan¬ 
ning/perception/mechanism  system.  The  testbed  (Fig.  7)  includes 
a  single  leg,  the  range  finder  mounted  on  top  of  the  “body"  of  the 
vehicle,  and  a  25m*  sandbox  that  simulates  the  terrain  in  which 
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Figure  6:  Processing  a  footfall  query 


the  lOver  will  navigate.  The  testbed  leg  was  built  from  an  earlier 
design,  as  a  result  it  is  slightly  different  from  the  legs  in  Rgnre  1. 
The  main  difference  is  that  the  testbed  leg  uses  rotational  joints 
while  the  design  of  Figure  1  uses  prismatic  joints.  A  real-time 
controller  drives  the  leg  to  specified  locations  in  Cartesian  or  joint 
space,  allowing  for  constraints  on  the  velocity  of  the  leg  and  the 
forces  applied  to  the  foot  In  addition,  the  body  can  be  translated 
aking  two  parallel  rails  by  coniroUing  the  two  horizontal  joints  of 
the  leg  while  keq>ing  the  foot  on  the  ground,  thus  simulating  the 
motion  of  the  body  in  the  actual  rover.  The  testbed  is  equipped 
with  a  linear  position  sensor  and  two  clinometers  that  together  give 
an  estimate  of  the  position  and  orientation  of  the  rover  with  respect 
to  the  global  frame. 


Hgure  7:  The  single  leg  testbed 

The  most  complicated  task  that  it  used  in  order  to  test  the 
peroqrtion  system  as  part  of  the  complete  single  leg  testbed  is  the 
so-called  'move-body*  task  in  which,  given  a  desired  length  of 


travel  and  a  desired  step  length,  the  leg  takes  a  series  of  steps, 
polling  the  body  forward  after  each  step.  The  locations  of  the 
footfalls  as  well  as  the  trajectory  of  the  leg  are  computed  using  the 
terrain  maps  from  the  perception  system. 

For  each  step,  the  sequence  of  operations  is  as  follows. 

1.  A  region  in  which  the  foot  may  be  placed  to  achieve  the  next 
step  is  computed  by  the  gait  planner  module. 

2.  The  gait  planning  module  queries  the  perception  system  for 
the  best  footfall  position  within  this  region.  This  query  ac¬ 
tivates  the  whole  cycle  of  taking  an  image,  computing  the 
terrain  map,  computing  the  footfall  evaluation  attribnte,  and 
replying. 

3.  Given  the  footfall  position,  the  leg  recovery  planning  module 
computes  a  path  for  the  leg  and  sends  a  region  around  this 
path  to  the  percq>tion  tytiem  requesting  a  map. 

4.  Perception  answers  the  query  by  sending  back  a  map  within 
the  specified  region,  including  the  uncertainty  attribnte. 

5.  The  planning  itMxlnle  uses  the  map  to  compute  the  locations 
of  intermediate  points  along  the  path  of  the  leg.  The  leg  is 
moved  to  the  goal  location  and  the  foot  is  lo’wtred  onto  the 
terrain  using  position  control.  The  uncertainty  is  used  as  a 
safety  margin  both  for  the  travel  of  the  leg  and  for  the  actual 
footfall.  In  the  latter  case  the  foot  is  lowered  to  a  position 
that  is  20  above  the  nominal  value  reported  in  the  terrain 
map.  and  then  lowered  using  force  control  until  it  contacts 
the  soil. 

Repeated  experiments  with  the  'move-body*  scenario  with 
different  terrain  shapes  and  different  initial  and  goal  configurations 
of  the  leg  have  shown  conclusively  that  the  first  version  of  the 
perception  system  performs  reliably  and  allow  the  system  to  safely 
walk  around  obstacles. 

Several  lessons  were  learned  during  these  experiments.  Good 
calibration  between  the  sensor  and  the  leg  is  essential  for  comput¬ 
ing  reliable  elevation  value  in  the  vehicle’s  reference  frame.  It  is 
important  to  use  information  already  extracted  when  possible,  if  an 
image  is  taken  whenever  a  query  is  received  we  then  run  the  risk  to 
have  the  leg  in  the  field  of  view  of  the  sensor  occluding  the  region 
of  interesL  The  solution  to  this  problem  is  to  include  in  the  per¬ 
ception  system  the  algorithms  that  extract  the  relevant  information 
from  the  existing  leniin  map  before  acquiring  new  data.  Finally,  it 
is  clear  from  those  experiments  that  more  development  is  needed 
u  far  as  the  computation  of  attributes  is  concerned.  The  only 
attributes  are  cturently  the  footfall  evaluation  and  the  uncertainty. 

6  Discussion 

We  have  presented  a  peroqttion  system  for  an  autonomous  vehicle 
designed  fur  planetary  exploration.  The  perception  system  uses 
terrain  maps  as  the  basic  internal  rqnesentation  that  is  accessed 
by  external  modules.  Partt  of  the  system  have  been  demonstrated 
using  algorithitu  for  building  temdn  maps  from  range  images.  The 
current  version  of  the  perception  system  has  been  included  in  a 
complete  single  leg  testbed. 

6.1  Improvements 

Several  improvements  are  needed  in  the  current  system.  First,  cal¬ 
ibration  is  of  critical  importance  for  the  successful  operation  of 
the  overall  system.  We  therefore  need  to  improve  the  calibration 
procedure  to  the  point  et  which  the  eiron  due  to  miscalibration  are 
minimal  compared  to  the  other  sources  of  errors.  This  involves  in 
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particular  a  nM>re  detailed  anatyais  of  the  geometry  of  the  mech¬ 
anism,  a  more  accnrate  model  of  the  sensor,  and  more  reliable 
algorithms  for  the  detection  of  calibration  targets. 

The  qnality  and  accuracy  of  the  terrain  maps  may  also  be  im¬ 
proved.  In  particular,  the  uncertainty  model  may  reflect  the  actual 
envirotunent  by  using  a  more  detailed  model  of  the  sensor  measure¬ 
ments.  Another  improvement  is  the  extensive  use  of  map  merging 
to  produce  more  accurate  maps  by  combining  many  measurements 
at  each  point  in  the  map. 

The  last  improvement  is  in  the  area  of  exception  handling. 
Currently,  the  perception  system  caruxit  recover  gracefully  from 
errors  such  as  corrupted  sensor  data,  bad  transformation  from  cor¬ 
rupted  position  readings,  or  bad  message  handling.  In  order  to 
have  a  robust  system  we  need  to  design  a  mechanism  to  detect  and 
recover  from  these  conditions. 

6^  Extensions 

Further  work  is  required  to  demonstrate  a  perception  system  that 
can  handle  the  tasks  of  a  complete  autonomous  system.  Other 
sensors  must  be  used  in  conjunction  with  the  laser  range  finder 
in  order  to  compute  i»n-geometric  types  of  information  such  as 
the  type  of  the  terrain  in  a  region.  This  is  important  both  for 
sampling  tasks,  which  require  the  identification  of  specific  types 
of  terrain,  and  for  the  evaluation  of  footfall  selection  since  the  soil 
compliance  depends  on  the  type  of  terrain.  The  best  candidates  are 
color  cameras  and  thermal  cameras.  We  are  woridng  on  integrating 
those  sensors  into  the  perception  system. 

Other  sensors  that  should  be  added  to  the  perception  sys¬ 
tem  include  sensors  for  short-range  perception,  such  as  proximity 
senson.  Those  sensors  would  be  used  in  the  final  phase  of  the 
footfall  to  provide  better  control  of  the  foot  contact  with  the  ter¬ 
rain.  Currently,  the  foot  is  lowered  to  a  nominal  value  given  by 
the  elevation  mq>,  after  which  point  it  is  slowly  lowered  until  a 
given  force  reaction  is  observed.  This  is  a  potentially  dangerous 
approach  if  the  map  is  inaccurate  at  that  point,  or  if  the  terrain  has 
changed  between  the  time  the  map  was  built  and  the  time  the  foot 
is  moved.  A  proximity  sensor  would  guarantee  that  the  foot  does 
not  attempt  to  penetrate  the  ground. 

The  perception  system  uses  only  local  information  from  its 
sensors.  A  possible  extension  would  be  the  addition  of  more  global 
infonnation  such  as  a  large-scale  map  from  an  orUter.  The  main 
issue  is  then  to  establish  the  relationship  between  the  low-resolution 
global  map  and  the  high-resolution  local  maps.  This  is  essentially 
a  matching  capability  that  can  greatly  enhance  the  performaiKes  of 
the  rover.  For  instance,  the  rover  could  register  itself  with  respect 
to  large-scale  terrain  features  from  the  global  map. 

Finally,  we  must  complete  the  inclusion  of  the  matching  of 
multiple  frames  in  the  system.  Map  matching  will  give  the  rover 
a  "self-localization*  ciqrability,  that  is  the  ability  to  register  itself 
with  respect  to  its  envirotunent  without  relying  entirely  on  special- 
purpose  position  sensors  (clinometers,  dead  reckoning,  INS).  It 
has  been  our  experience  that  those  sources  of  position  information 
catmot  be  relied  upon  at  all  time  because  they  do  not  necessarily 
give  an  accnrate  description  of  the  position  and  orientation  of  the 
sensor  at  the  time  an  image  is  taken.  Furthermore,  they  have  to  be 
carefully  calibrated  with  respect  to  the  perception  sensors  which 
add  arwther  level  of  complexity  tt>  the  already  difficult  calibration 
problem.  The  solution  be  to  use  the  onqrut  of  the  position 
sensors  u  an  initial  estimate  for  the  map  matching  process  which 
will  provide  the  accurate  position  estimate  actually  used. 


63  Remaining  Issues  and  Lessons  Learned 

In  the  course  of  developing  tins  system  we  have  encountered  the 
usual  fundamental  issues  in  the  design  of  autonomous  systems  [5], 
and  had  to  make  choices  to  overcome  those  problems.  Two  issues 
were  of  special  interest:  the  mode  of  synchronization  between  the 
perception  system  and  the  other  modules,  and  the  limitations  due 
to  message-passing  between  modules. 

The  architecture  is  currently  entirely  query-driven  in  that  the 
terrain  maps  are  computed  only  in  response  to  a  specific  query 
from  another  module.  This  may  not  be  the  best  strategy  in  a 
system  that  includes  many  other  computation-intensive  modules. 
In  that  case,  the  percqrtion  system  would  be  idle  most  of  the  time. 
A  differem  strategy  would  be  firr  the  perception  system  to  ke^ 
computing  the  terrain  map  around  the  vehicle  even  if  no  query 
has  been  received.  That  way,  the  perception  would  take  advantage 
of  the  idle  time  to  perform  some  additional  computations.  The 
main  issue  is  for  the  perception  system  to  be  able  to  predict  the 
regions  of  the  envirotunent  that  will  be  "useful"  to  compute  for 
the  fumre  queries.  This  also  requires  a  careful  analysis  of  the 
synchronization  between  modules  so  that  this  self-driven  approach 
does  not  accidentally  slow  down  the  other  modules.. 

Our  experience  with  tins  system  has  been  that  the  communi¬ 
cation  baitdwidth  using  conventional  network  techrwlogy  is  not  a 
limitation.  In  this  application,  shipping  images  and  m^s  between 
the  different  modules  of  the  perception  system  and  the  other  mod¬ 
ules  does  not  affect  the  performance  of  the  overall  system  signifi- 
tcantiy.  There  are  still  some  synchronization  issues  to  be  addressed, 
however.  The  most  important  one  is  to  guarantee  that  the  position 
of  the  vehicle  is  correctly  read  at  the  time  that  an  image  is  taken 
(Section  3.2),  which  is  not  possible  if  there  is  ux>  much  of  a  delay 
between  the  ISM  and  the  module  that  sends  the  vehicle  position. 
One  solution  is  to  jypass  the  central  message  handler  completely 
for  some  of  the  low-level  operations  such  talcing  an  image  so  that 
the  communications  are  performed  by  direct  memory  transfer  with 
minimal  delay. 
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Experience  with  a  Task  Control 
Architecture  for  Mobile  Robots 
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Abstract 

This  paper  presents  a  general-purpose  architecture  for  controlling  mobile  robots,  and  describes  a 
working  mobile  manipulator  which  uses  die  architecture  to  operate  in  a  dynamic  and  uncertain 
environment.  The  target  of  this  work  is  to  develop  a  distributed  robot  architecture  for  planrang, 
execution,  monitoring,  exception  handling,  and  multiple  task  coordinatioa  We  report  our  progress  to 
date  on  the  architecture  development  and  the  performance  of  the  working  robot.  In  particular,  we  discuss 
temporal  reasoning,  execution  monitoring,  and  context-dependent  exception  handling. 
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1.  Introduction 

The  principal  goal  of  this  work  is  to  develop  a  distributed  robot  architecture  to  support  robot  planning, 
execution,  monitoring,  exception  handling,  and  multiple  task  coordinatioru  We  have  been  developing 
such  a  robot  architecture,  called  Jie  Task  Control  Architecnire  (TCA)I15],  TCA  is  designed  for 
controlling  mobile  robots  that  have  limited  computational  and  sensory  resources,  operate  in  uncertain, 
changing  (but  relatively  benign)  environments,  have  multiple  goals,  and  have  a  variety  of  strategies  to 
achieve  goals  and  handle  exceptions. 

We  have  been  developing  TCA  concurrently  on  two  testbeds  —  the  CMU  six-legged  Planetary  Rover 
[3]  and  the  Heath/Zenith  Hero  2000  mobile  manipulator  robot  [12].  The  CMU  Rover  projea  is  an 
attempt  to  develop  an  autonomous  robot  that  can  survive,  navigate,  and  acquire  samples  on  the  Martian 
surface.  The  Hero  testbed  is  an  indoor  platform  that  has  been  used  to  drive  the  architecture  design.  The 
current  capabilities  of  the  Hero  include  collecting  cups  in  the  laboratory  artd  recharging  itself. 

Our  initial  implementation  on  the  Hero  robot  [12],  which  was  developed  in  an  ad  hoc  marmer,  had 
several  shortcominp.  It  was  slow  and  slack  in  reacting  to  environmental  changes.  It  could  not  protect 
itself  and  recover  from  failures  properly.  It  also  could  not  change  its  focus  to  higher-priority  tasks  or 
respond  to  requests  from  human  advisors.  After  re-implementing  the  testbed  using  mechanisms  and 
functions  provided  by  TCA.  most  of  these  shortcominp  have  been  minimized.  The  robot  is  rx)w  faster 
and  more  robust  It  can  react  to  environmental  changes  in  a  reasonable  time  frame,  and  it  has  a  variety  of 
strategies  to  recover  from  failures. 

The  following  are  the  capabilities  that  TCA  currently  supports. 

•  Concurrent  planning  and  execution.  Robots  often  take  a  significant  amount  of  time  in 
constructing  plans.  Since  planning  and  execuUrm  are  activities  that  often  need  different 
resources,  both  can  occur  concurrently.  However,  this  concurrency  sometimes  needs  to  be 
constrained.  In  many  cases,  the  robot  must  act  on  an  incomplete  plan  and  defer  some  specific 
decisions  until  more  information  can  be  acquired.  On  the  other  hand,  to  minimize  risk  to  the 
robot,  one  might  want  to  completely  plan  out  a  goal  before  executing  any  of  its  sub- 
conunands. 

•  Reacting  to  environmental  changes.  To  accomplish  tasks,  and  even  to  survive,  the  robot 
must  be  reactive.  It  must  always  be  aware  of  environment^  changes,  and  respond  to  them 
appropriately  and  in  a  timely  manner.  Some  environmental  changes  invalidate  current  plans, 
while  others  may  demand  the  robot  to  change  its  focus  completely. 

•  Error  recovery.  In  complicated,  changing  environments,  failures  are  bound  to  occur.  When 
they  do  occur,  the  robot  must  change  its  plan  to  meet  the  new  situation.  Error  recovery  is 
oftra  context-dependent,  that  is,  the  same  failure  may  have  to  be  handled  differently, 
depending  on  the  robot’s  intentions.  Since  in  a  boiign  environment,  the  failed  plan  is  often 
close  to  being  correct,  it  is  desirable  for  the  robot  to  be  able  to  fix  and  re-use  the  problematic 
plan,  instead  of  always  replaruiing  from  scratch. 

•  Coordinating  Multiple  Tasks.  With  many  simultaneous  goals  but  limited  resources,  the 
robot  must  be  able  to  dynamically  prioritize  and  schedule  its  various  tasks  based  on  their 
urgency,  relative  costs,  l&eiihoods  of  success,  etc.  Currently,  only  simple-minded  strategies 
can  be  specified  using  TCA,  but  we  envision  taking  a  more  knowledge  intensive  approach  in 
the  near  future. 

Various  TCA  mechanisms  have  been  developed  to  support  these  capabilities. 

•  Distributed  processing.  TCA  is  a  distributed  architecture  with  centralized  control.  A  robot 
system  using  TCA  includes  a  central  control  and  a  number  of  concurrent,  application-specific 
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processes.  We  believe  that  a  centralized  control  architecture  facilitates  the  coordination  of 
multiple  complex  robot  behaviors,  while  the  distributed  processing  allows  for  concurrency  in 
planning,  execution,  and  perception. 

•  Resources.  TCA  provides  a  mechanism  to  schedule  the  use  of  the  robot’s  limited 
computational  and  physical  resources.  A  is  automatically  queued  by  TCA  until  the 
needed  resources  are  available.  Resource  reservation,  together  with  temporal  constraints  (see 
below),  provide  synchronization  mechanisms  to  control  distributed  robot  systems. 

•  Task  trees  and  temporal  constraints.  In  TCA,  planning  and  execution  are  separate 
activities  and  can  be  performed  concurrently.  The  interleaving  of  these  activities  can  be 
constrained  by  imposing  temporal  constraints  among  the  planning  and  achievement  times  of 
subgoals.  TCA  explicitly  maintains  the  goal/subgoal  hierarchies,  called  task  trees.  Task 
trees,  together  with  the  temporal  constraints,  are  TCA’s  representation  of  plans. 

•  Concurrent  monitors.  Concurrent  monitors  enable  the  robot  to  watch  for  environmental 
changes  in  parallel  with  normal  task  execution.  Because  task  execution  and  monitoring  occur 
concurrently,  the  performance  of  tasks  will  not  be  (significantly)  slowed  down,  while  still 
enabling  environmental  changes  to  be  detected  as  early  as  possible. 

•  Exception  handling.  TCA  provides  a  general  mechanism  for  handling  planning  time 
failures,  execution  time  errors,  and  contingencies.  The  robot  implementor  can  specify 
different  strategies  for  handling  the  same  exception  in  different  contexts.  One  benefit  of 
having  this  mechanism  is  to  allow  the  user  to  separate  robot  behaviors  for  normal  situations 
fiom  these  that  handle  failures  or  contingencies,  hi  diis  way,  cmnplex  robot  behaviors  can  be 
developed  incrementally,  and  exception  handling  can  be  flexibly  defined.  At  present,  the 
mechanism  is  still  under  construction  but  some  primary  results  have  been  obtained. 


Table  !•!  summarizes  the  supporting  relationslilps  between  the  T(L\  mechanisms  and  desired  robot 
capabilities.  A  mark  "X"  in  an  entry  of  the  table  indicate  that  the  mechanism  in  that  column  is  used  to 
support  the  capability  in  that  tow.  Note  that  although  synchronization  by  itself  is  not  a  capability  needed 
by  robots,  it  plays  an  important  role  in  the  distributed  environment  of  TCA. 

Table  1-1:  The  supporting  relationships  between  mechanisms  and  capabilities 
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X 

X 
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X 
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The  test  rf  this  paper  presents  the  Hero  robot  system,  the  Task  Control  Architecture,  and  their 
performance.  Section  2  describes  the  hardware  setup  of  the  system  and  gives  a  scenario  to  illustrate  how 
the  Hero  robot  performs  tasks.  Section  3  discusses  the  various  mechanisms  of  TCA.  Section  4  describes 
the  robot  system  in  detail.  Performance  of  the  robot  and  TCA  is  evaluated  in  Section  S.  Comparisons 
with  related  work  arc  given  in  Section  6.  Finally  the  paper  is  concluded  in  Section  7. 
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2.  Scenario 

Our  mobile  manipulator  robot,  the  Heath/Zenith  Hero  2000,  is  a  commercially  available  wheeled  robot 
with  a  two-finger  hand  (see  Figure  2-1).  The  robot  operates  in  an  unstructured  laboratory,  which  is 
observable  through  a  ceiling-mounted  camera  (see  Figure  2-2).  The  Hero  robot  has  three  sonar  sensors;  a 
rotating  sonar  on  top,  a  forward-pointing  sonar  fixed  to  its  base,  and  one  mounted  on  the  robot’s  hand 
which  can  be  repositioned  relative  to  the  body.  In  addition,  the  robot  has  a  battery  charge  level  sensor,  a 
rotating  light  intensity  sensor,  and  touch  sensors  on  the  fingers.  Using  existing  vision  software  [10],  we 
developed  a  2D  vision  subsystem  for  the  ceiling  camera.  We  also  developed  algorithms  for  navigation 
and  manipulation  in  the  indoor  environment 


Figure  2-1:  The  Hero  2000  Robot 

When  the  system  is  started  up,  the  robot  is  given  several  high-level  goals,  including  (1)  collecting  cups 
discovered  on  the  lab  floor  and  placing  them  in  a  receptacle,  (2)  avoiding  obstacles,  and  (3)  recharging  its 
battery  when  necessary.  The  rest  of  this  section  presents  a  scenario  to  illustrate  how  the  robot  achieves 
and  coordinates  these  goals. 

For  the  cup  collection  task,  the  robot  monitors  its  2D  vision  map  for  the  appearance  of  cups  on  the 
floor.  An  asynchronous  perception  process  continually  takes  a  picture  and  updates  a  world  map.  Once  a 
new  map  is  built,  the  robot  scans  the  map  to  find  cup-like  objects.  In  this  scenario,  two  cup-like  objects 
are  spotted,  and  the  system  sets  up  two  cup-collection  goals  and  temporally  orders  them  so  that  the  closer 
objea  will  be  explored  first 

The  robot  then  plans  and  executes  a  path  to  the  first  object  While  moving,  it  monitors  for  obstacles  in 
its  path.  A  monitor,  whose  temporal  extent  continues  until  the  objea  is  picked  up,  is  created  to  ensure 
that  the  target  object  does  not  disappear  (e.g.,  someone  else  may  pick  it  up).  Upon  arriving  near  the 
object  the  robot  uses  its  wrist  sonar  to  measure  the  height  and  width  of  the  object  and  matches  them 
against  its  cup  models.  If  a  satisfactory  match  is  found,  the  robot  plans  and  executes  actions  to  pick  up 
the  object  In  parallel  with  measuring  and  picking  up  the  object,  the  robot  uses  its  overhead  vision  map  to 
pre-plan  a  path  to  the  receptacle  so  that  a  path  plan  is  ready  for  execution  when  the  cup  is  picked  up.  The 
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Figure  2*2:  Overhead  View  of  Laboratory  as  Seen  by  Robot 


robot  then  uses  the  plan  to  navigate  to  the  receptacle,  where  it  deposits  the  cup. 

Next,  the  robot  attends  to  collecting  the  other  object  While  moving  toward  the  object  the  robot 
notices  (from  either  its  oveihead  vision  or  its  sonar  sensors)  that  an  object  appears  in  into  its  path.  The 
robot  stops  immettiately  and  waits  to  see  if  the  objea  will  move  away  soon.  If  the  obstacle  does  not 
move,  the  robot  plans  a  detour  by  modifying  the  blocked  path  plan.  If  no  detour  can  be  found,  the  robot 
replans  a  path  from  scratch.  If  still  no  path  can  be  found,  the  robot  abandons  this  cup-coUection  goal. 

In  this  scenario  a  detour  is  found,  so  the  robot  continues  to  navigate  to  the  objecL  The  robot  finally 
arrives  near  the  object  and  starts  measuring  it  At  this  point,  the  battery  charge  monitor  notifies  the  robot 
that  its  battery  charge  is  getting  low.  Based  on  the  simple-minded  strategy;  "if  the  robot  has  arrived  near 
the  objea  complete  the  task  before  going  over  to  recharge”,  the  robot  creates  a  recharge  goal  with 
temporal  constraints  indicating  that  the  new  goal  will  be  attended  to  after  the  cup-collection  goal  is 
achieved  or  aborted.  The  robot  continues  and  subsequently  discovers  that  the  objea  is  i»t  a  cup  at  all.  It 
gracefully  terminates  all  ongoing  and  pending  activities  and  monitors  that  were  set  up  for  collecting  the 
object,  and  then  it  chooses  to  pursue  its  next  goal,  which  is  the  recharge  goal. 


3.  The  Task  Control  Architecture 

T(ZA  is  designed  to  implement  cr^rabilities  we  believe  to  be  necessary  for  autonomous  robots.  TCA  is 
a  distributed  architecture  with  centralized  control.  An  application  of  TCA  includes  a  central  process  and 
a  number  of  concurrent,  application-specific  processes,  called  modules.  Communication  occurs  via 
coarse-grained  message  passing  between  modules,  with  all  messages  being  routed  through  the  central 
process. 

To  facilitate  experimentation  with  diffetent  control  schemes,  TCA  is  built  as  a  layered  system  so  that  an 
implementor  can  choose  which  layers  to  use  -  higher  layers  provide  more  functionality  specific  to  robot 
control,  but  lower  layers  provide  flexibility  to  implement  alternative  control  schemes. 
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At  present,  the  implemented  layers  include: 

•  Communication  layer  that  supports  distributed  processes  under  centralized  conUDl; 

•  Behavior  layer  for  querying  the  environment,  specifying  goals,  executing  commands,  and 
altering  the  robot’s  ituemal  sute 

•  Resource  layer  for  allocating  and  managing  physical  and  computational  resources: 

•  Task  management  layer  for  building  hierarchical  plan  structures  and  specifying  temporal 
constraints  between  planning  and  execution  of  various  goals  in  the  plan; 

•  Monitor  layer  for  concurrently  monitoring  user-selected  aspects  of  the  robot’s  external  and 
internal  envirorunents; 

•  Exception  handling  layer  for  specifying  context-dependent  strategies  for  handling  plan 
failures,  execution  errors,  and  envirorunental  changes. 

In  addition,  other  layers  to  support  multi-task  coordination  and  user  interaction  are  plaimed. 


3.1.  Communication  Layer 

The  base  layer  of  functionality  provided  by  TCA  is  the  sending  and  receiving  of  messages  between 
modules.  Modules  can  be  written  in  different  languages  (currently  both  Lisp  and  C  are  supported)  and 
tun  on  different  machines  (using  the  UNIX  TCP  protocol).  In  essence,  TCA  provides  a  simple  remote 
procedure  caIf(RPQ  interface  from  a  caller  in  one  module  to  a  procedure  in  a  possibly  remote  module. 
The  main  difference  between  typical  RPC  implementation  and  TCA  is  that  the  central  control  determines 
which  module  handles  messages  and  in  what  order  they  are  handled. 

A  potential  problem  with  centralized  conuol  is  that  the  central  process  may  become  a  bottleneck. 
Experimentally,  a  round-trip  time  for  messages  of  under  lOK  bytes  is  about  SO  milliseconds.  Since  this 
time  is  small  compared  with  the  time  taken  by  image  processing,  planning,  and  the  robot’s  actuators,  the 
centralized  control  has  not  been  a  problem  on  our  current  testbeds.  Besides,  the  potential  bottleneck 
problem  can  be  overcome  by  using  high-speed  hardware  (e.g.,  the  Nectar  [2])  and  adhering  to  some 
conventions,  sudi  as  using  coarse-grained  behaviors  to  limit  the  amount  of  module-to-module 
communicatioa 


32.  Behavior  Layer 

TCA  provides  several  types  of  primitive  building  blocks  needed  to  construct  robot  behaviors.  The 
primitive  behaviois  are  implemented  as  different  classes  of  messages,  built  on  top  of  the  communication 
layer.  The  classes  differ  mainly  in  their  control  flow.  For  example,  query  messages  block  the  user’s  code 
until  a  reply  is  received,  while  goal  and  command  messages  are  non-blocking  and  report  success  or 
failure  directly  to  the  central  control. 

•  Query  messages  are  requests  to  provide  information  about  the  external  or  internal 
envirorunent,  such  as  obtaining  a  world  map  or  determining  the  robot’s  dead-reckoned 
position. 

•  Gkral  messages  are  intended  to  support  top-down,  hierarchical  planning.  A  typical  response 
to  a  goal  message  would  be  to  issue  other  (sub)goal  and/or  command  messages  based  on  the 
results  of  planning.  Unlike  queries,  goal  messages  are  asynchronous  and  non-blocking.  That 
is,  the  ceinral  control  may  queue  the  goal  until  resources  become  available;  in  the  meanwhile, 
the  module  sending  the  god  message  can  continue.  The  rationale  is  that  non-blocking  goal 
messages  give  the  implementor  greater  flexibility  in  controlling  the  achievement  of  goals 
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(e.g..  interleaving  planning  and  execution). 

•  Command  messages  are  used  to  execute  actions.  Like  goal  messages,  command  messages 
are  asynchronous  and  non-blocking.  Distinguishing  goal  from  command  messages  is  done 
mainly  for  inteiicaving  planning  and  execution. 

•  Constraint  messages  provide  a  way  to  alter  tire  robot's  internal  state.  For  example, 
constraint  messages  can  be  used  to  add  expectations  about  its  future  behaviors. 

3  J.  Resource  Layer 

It  is  crucial  for  an  autonomous  agent  to  effectively  allocate  its  limited  resources  in  order  to  satisfy  its 
goals.  The  robot  must  detect  when  tasks  need  competing  resources,  and  must  prioritize  and  schedule 
tasks  when  conflicts  occur.  In  TCA,  a  resource  is  an  abstract  entity  that  is  used  to  manage  the  handling  of 
messages.  A  resource  may  be  associated  with  a  computational  entity,  such  as  a  module,  or  with  a 
physical  entity,  such  as  a  motor  or  camera. 

Resources  are  created  with  a  cr^acity  -  the  number  of  messages  the  resource  can  handle 
simultarreously.  A  message  received  by  the  central  control  is  queued  until  the  resource  that  handles  the 
message  has  available  capacity.  Currently,  messages  to  the  same  resource  are  handled  in  FIFO  order, 
subjea  to  the  temporal  constraints  imposed  by  the  task  managemetu  layer.  ^ 

Sometimes,  a  module  might  need  control  over  a  resource  for  some  period  of  time,  particularly  one 
associated  with  a  physical  item.  For  example,  if  a  vision  module  is  acquiring  an  image,  it  might  want  to 
ensure  that  the  robot  does  not  move  during  that  period.  To  facilitate  this,  TCA  includes  mechanisms  for 
reserving  resources,  in  effect,  preventing  other  modules  from  utilizing  the  resource  until  the  reservation  is 
explicitly  canceled.  Resource  reservation  is  one  of  the  synchronization  constructs  in  TCA. 


3.4.  Task  Management  Layer 

The  task  managemem  layer  provides  mechanisms  for  organizing  sets  of  messages  into  hierarchical  task 
trees  (see  Figure  3-1).  For  each  goal,  command,  or  monitor  mes;>age  seru  'uy  •  module,  TCA  adds  a  node 
to  the  task  tree  as  a  child  of  the  node  that  issued  the  message.  The  resulting  tree  is  an  execution  of  graph 
of  messages  used  to  complete  a  given  task.  In  addition,  facilities  have  been  developed  for  tracing  and 
manipulating  the  task  tree,  such  as  killing  off  subtrees,  suspending  them,  and  adding  new  nodes.  These 
facilities  will  provide  functionalities  rreeded  by  some  of  the  higher  layers,  such  as  the  exception  handling 
layer  (see  Section  3.6)  and  the  plaimed  multi-task  coordination  layer. 

Another  importaru  purpose  of  this  layer  is  for  scheduling  tasks.  The  layer  contains  a  general  facility  for 
reasoning  about  time.  In  TCA,  by  default  planning  and  execution  can  occtir  concurrently.  Interleaving  of 
plarming  and  execution  can  be  constrained  by  imposing  temporal  constraints  on  the  planning  times  of 
goals  arxi  achievemem  times  of  goals,  commands,  and  mtmirors.  For  example,  a  module  might  specify 
that  the  adiievement  time  of  G1  precedes  that  of  G2,  but  the  planning  time  of  G2  precedes  that  of  G1 
(e.g.,  first  achieve  pick  up  the  cup.  then  bring  it  to  the  receptacle,  but  plan  the  route  to  the  receptacle 
before  planning  how  to  pick  up  the  cup).  Similarly,  a  module  might  constrain  a  goal  to  be  completely 
planned  before  any  of  its  sub-commands  can  start  being  achieved. 


'We  pirn  to  add  more  sophisticated  scheduling  mechanisms  in  the  future. 
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Figure  3*1:  Sample  task  tree 

The  mechanisms  for  reasoning  about  temporal  constraints  are  based  on  the  Quantity  Lattice  [13],  an 
arithmetic  reasoning  system,  that  integrates  relationships,  arithmetic  expressions,  qualitative  and 
quantitative  information  to  perform  a  wide  range  of  common  arithmetic  inferences.  In  TCA,  it  is  used  to 
maintain  a  consistem  partial  order  of  time  points  and  to  answer  queries  about  relationships  between  time 
points  and  about  the  durations  of  intervals. 

With  the  temporal  mechartisms  provided,  robot  implementors  can  formulate  a  fairly  wide  range  of 
different  constraints  to  take  advantage  of  concurrencies  in  the  distributed  environment  of  TCA.  Together 
with  resource  reservation,  the  temporal  constraints  provide  synchronization  mechanisms  to  control 
distributed  robot  systems. 

3.5.  Monitor  Layer 

To  react  to  environmental  changes,  robots  must  first  be  able  to  monitor  the  environment  and  detea 
changes  in  time.  Although  in  the  real  world  many  things  may  go  wrong  at  any  time,  robots  with  limited 
sensory  resources,  such  as  ours,  carmot  afford  to  monitor  everything  that  goes  on  in  the  environmenL  The 
monitor  layer  provides  mechanisms  to  monitor  user>selected  aspects  of  the  environment  and  repon 
detected  changes  to  the  central  control  for  handling.  Monitors  in  TCA  run  concurrently  with  normal  task 
execution.  For  example,  the  Hero  robot  attends  to  the  cup  collection  goal  while  monitoring  for  obstacles 
and  its  battery  charge. 

A  monitor  specifies  the  condition  to  be  monitored,  and  the  time,  relative  to  other  messages,  when 
monitoting  is  to  take  place.  When  the  condition  holds,  a  typical  action  would  be  to  send  an  exception 
message  to  the  central  control,  which  will  decide  what  to  do  based  on  the  environment  and  context  in 


^The  qiuniiuiive  reasoning  capability  of  the  Quantity  Lauice  is  not  yet  utilized  by  TCA. 
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which  the  exception  occurred  (see  Section  3.6). 

Two  classes  of  monitors  are  implemented:  point  monitors  and  interval  monitors.  Point  monitors,  which 
test  the  monitor’s  condition  just  once,  are  useful  for  checking  static,  execution  time  conditions,  such  as 
checking  the  pre-condition  or  post-condition  of  a  conunand  or  goal.  Interval  monitors,  which  have  a 
temporal  extent,  ate  useful  for  checking  for  environmental  changes  over  time. 

TCA  has  two  variations  of  interval  monitors:  polling  and  demon  monitors.  Polling  monitors  implement 
synchronous  polling  of  conditions  at  a  fixed  frequency,  while  demon  monitors  implement  asynchronous 
demon-invocation.  For  instance,  the  battery  monitor  of  the  Hero  robot,  which  is  a  polling  monitor, 
periodically  checks  the  battery  charger  and  raises  an  exception  if  a  low  charge  is  detected.  The  cup 
appearance  monitor,  implemented  as  a  demon  monitor,  is  invoked  whenever  a  world  map  is  updated  by 
the  asynchronous  perception  process,  and  checks  the  wortd  map  for  cup-like  objects,  raising  exceptions  if 
such  objects  are  found. 

Monitors  can  also  be  used  to  construct  conditional  plans.  For  instance,  suppose  there  are  two  strategies 
to  achieve  goal  G,  but  we  do  not  know  in  advance  which  one  will  be  applicable.  We  can  set  up  a  monitor 
to  check  the  envirorunent  and  choose  the  appropriate  strategy  at  execution  time. 


3.6.  Exception  Handling  Layer^ 

Exceptions  can  be  divided  into  three  classes,  according  to  the  ways  they  are  detected. 

•  failures  deteaed  in  planning  (e.g.,  no  path  to  the  cup); 

•  errors  detected  in  executing  commands  (e.g.,  wheel  slippage); 

•  contingencies  detected  by  monitors  (e.g..  low  battery  charge). 

TCA  employs  the  same  mechanisms  to  handle  the  three  different  types  of  exceptions. 

Exception  handling  is  often  context-dependenL  the  same  exception  might  need  be  handled  differently, 
depending  on  the  envirorunent  and  where  in  the  plan  the  exception  occurs.  For  example,  a  wheel 
blockage  is  a  failure  if  it  is  detected  when  the  robot  is  navigating  in  an  open  space.  But  it  could  be  a 
signal  of  a  successful  docking  if  the  robot’s  goal  is  to  dock  on  the  charger.  To  facilitate  context- 
dependent  exception  handling,  TCA  supports  mechanisms  for  associating  exception  handlers  with 
contexts  at  plaruiing  time  and  automatically  invoking  the  handlers  when  exceptions  are  raised.  Various 
utilities  are  also  provided  to  enable  harxllers  to  fix  problematic  plans. 

The  context  of  an  exception  handler  is  established  by  attaching  the  handler  to  a  task  tree  node.  This 
association  is  done  dynamically  as  the  task  tree  is  created.  When  an  exception  is  raised,  TCA  searches  up 
the  task  tree,  starting  horn  the  node  where  the  exception  arose,  to  find  a  handler  specific  to  that  exception. 
The  first  matched  handler  is  then  invoked  to  handle  the  exception. 

Exception  handling  is  achieved  by  editing  the  task  tree,  for  example,  by  deleting  part  of  it  and  inserting 
some  new  nodes.  The  exception  handlers  can  use  the  task  tree  operations  provided  by  the  task 
management  layer  to  access,  scrutinize,  and  then  modify  the  task  tree.  Modifications  to  task  trees  may 
include  terminating  or  suspending  the  execution  of  subtrees,  and  adding  new  nodes  to  the  task  tree,  which 


^Currently,  only  the  framework  of  the  exception  handling  layer  has  been  implemented,  and  various  supporting 
mechanisms  are  still  under  construction. 
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is  then  expanded  using  the  nonnal  TCA  mechanisms.  To  illustrate.  Figure  3-2(a)  shows  a  situation  where 
a  battery  charge  monitor  is  set  up  and  the  robot  is  actively  attending  to  the  cup-collection  goal.  When  the 
monitor  detects  a  low  battery  charge,  the  low  battery  charge  handler  attached  to  the  root  node  is  chosen 
to  handle  it  After  checking  the  battery  charge  and  the  progress  of  the  cup  collection,  the  handler  decides 
to  recharge  first  and  finally  ends  up  with  the  situation  in  Figure  3*2(b),  where  the  monitor  has  been 
canceled,  the  cup-collection  goal  has  been  suspended,  and  the  recharge  goal  has  been  added  and  become 
the  current  goal. 


If  an  exception  handler  finds  it  cannot  actually  handle  the  situation,  it  can  raise  an  exception  itself. 
When  the  central  control  receives  an  exception  from  an  exception  handler,  the  search  for  a  ctqsable 
handler  is  resumed,  starting  ftom  the  node  where  the  previous  handler  was  found  and  searching  up  the 
task  tree.  This  process  is  repeated  until  the  exception  is  successfully  handled.  As  a  catchall,  TCA 
attaches  a  general  exception  handler  to  the  root  node  of  the  task  tree.  When  invoked,  this  general  handler 
simply  deletes  the  failed  task  along  with  all  its  subtasks. 

This  TCA  approach  to  exception  handling  is  efficient  First  the  invocation  of  exception  handlers  is 
fast  because  only  a  simple  search  on  the  task  tree  is  involved.  Second,  TCA  allows  a  problematic  plan  to 
be  fixed  and  re-used  as  much  as  possible.  For  example,  when  moving  obstacles  appear  unexpectedly,  the 
Hero  robot  first  waits  for  obstacles  to  move  away.  If  they  do  not  move  away,  it  tries  to  plan  a  detour  by 
modifying  the  blocked  path  plaa  If  no  detour  is  found,  a  new  path  is  platmed  from  scratch.  Only  if  no 
path  is  found  is  the  task  terminated. 

4.  The  Hero  Robot  System 

The  Hero  robot  system,  which  uses  TCA,  presently  consists  of  five  modules  plus  the  central  control 
(see  Figure  4-1).  In  this  section,  we  describe  the  functionalities  of  the  modules  and  how  they  interact  with 
each  other. 


Figure  4-1:  Organization  of  the  robot  testbed 


\ 
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Controller.  This  module,  which  controls  the  robot  via  either  a  radio  link  or  an  RS232  cable,  executes 
navigation  commands  (e.g.,  turn,  move)  and  manipulation  commands  (e.g..  raise  arm,  open  grippers).  It 
also  handles  queries  that  involve  using  sensors  on  the  robot,  for  example,  reading  the  battery  charge  level, 
and  measuring  the  height  of  an  object  using  the  wrist  sonar. 

The  Controller  also  keeps  track  of  the  robot’s  trajectory  and  handles  trajectory  queries.  Because  of  the 
control  error,  the  uncertainty  about  the  robot’s  position  will  grow  over  time.  The  Controller  utilizes  a 
covariance  matrix  representation  [16]  to  model  the  control  error,  and  compounds  the  uncertainty 
whenever  the  robot  moves  or  turns.  'This  uncertainty  information  is  primarily  used  by  the  Perception 
Query  Handler  to  determine  the  likelihood  of  hitting  obstacles  in  the  course  of  navigation. 

We  also  implemented  reflexive  guarded  move  commands  directly  on-board  the  Hero.  These  give  the 
robot  a  higher  degree  of  reactivity  than  could  be  gotten  from  centralized  control  While  the  robot  is 
moving  or  turning,  the  on-board  CPU  detects  wheel  slippage  and  blockage  by  monitoring  the  motor 
encoders.  At  the  same  time,  the  sonar  sensors  are  used  to  detea  obstacles  in  the  robot’s  trajectory.  In 
both  cases,  the  reflex  action  is  to  stop  the  robot  immediately.  st?bili2ing  it  Then  the  Controller  signals  a 
failure  so  that  the  system  can  rectify  the  situation  using  the  exception  handling  mechanisms. 

World  Map  Builder.  This  module  coruinually  takes  and  processes  im^es  of  the  lab  (every  20 
seconds  or  so),  and  updates  a  world  map,  which  is  then  forwarded  to  the  Perception  Query  Handler.  We 
have  found  that  this  asynchronous  process  has  substantially  increased  the  performance  of  the  robot 
compared  with  our  previous  system.  For  example,  since  a  relatively  up-to-date  world  map  is  always 
available,  die  robot  does  not  need  to  wait  for  processing  an  image  in  order  to  find  a  cup-like  objea  or  to 
plan  a  path. 

To  identify  the  robot  in  the  image,  the  World  Map  Builder  first  gets  the  robot’s  dead-reckoned 
trajectory  from  the  Controller.  Based  on  the  trajectory  and  other  information  such  as  the  size  of  the  robot, 
the  robot  region  can  often  be  distinguished  from  other  object  regions.  Two  failures,  however,  can  be 
encountered.  Rrst,  the  robot  may  not  be  successfully  spotted,  because  the  robot  region,  for  example, 
overlaps  another  visual  legiort  This  failure  is  handled  by  taking  an  image,  moving  the  robot  a  few 
inches,  taking  another  image,  and  comparing  the  differences  in  the  images  to  spot  the  robot  The  second 
failure  occurs  when  the  light  in  the  lab  is  turned  off.  This  exception  is  handled  by  asking  humans  to  turn 
on  the  light  or  going  to  sleep  (i.e.,  turning  off  the  power  to  all  circuitry  except  the  memory)  if  no  help  is 
secured. 

Perception  Query  Handler.  The  Perception  Query  Handler  provides  three  kinds  of  functionality. 
First  it  updates  the  world  map  upon  receiving  a  new  m^  from  the  World  Map  Builder.  Second,  it 
handles  perception  demons.  When  a  new  world  map  is  received,  perception  demons  are  invoked  to  check 
conditions  that  they  monitor.  Presently  there  are  two  kinds  of  demons  that  can  be  set  up  -  cup  appearance 
monitors  and  objea  monitors  (for  checking  if  an  object  remains  at  a  specified  position  on  the  floor). 

The  third  task  of  this  module  is  to  handle  perception  queries,  including 

•  calculating  the  vicinity  of  an  objea  in  order  to  approach  it, 

•  checking  if  a  path  is  clear,  based  on  uncertainty  reasoning, 

•  reducing  the  uncertainty  about  the  robot’s  location  and  orientation  by  using  vision. 

As  mentioned  previously,  the  Controller  explicitly  models  the  uncertainty  of  the  robot’s  status.  When  the 
robot  is  executing  a  path  plan,  the  Perception  Query  Handler,  given  the  uncertainty  information,  would  be 
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asked  to  determine  (1)  if  the  path  is  clear,  (2)  if  yes.  how  far  the  robot  may  safely  proceed  along  the  path 
before  the  uncertainty  cone  overlaps  object  regions  (see  Figure  4-2).  If  the  uncertainty  has  grown  to  the 
extent  that  collisions  with  obstacles  are  possible,  the  Perception  Query  Handler  uses  vision  to  reduce  the 
uncertainty.  To  do  this,  it  first  takes  a  picture  of  the  robot  and  calculates  the  robot  status  (including  visual 
uncertainty)  based  on  properties  of  the  robot’s  shape  and  internal  model  of  sensor  uncertainty.  A  new 
robot  status  is  then  obtained  by  merging  the  observed  and  expected  status  [16]. 


Figure  4*2: 

Interpreted  Version  of  the  Image  from  Figure  2-2  with  Planned  Path  and  Uncertainty 
Cone.  The  brightened  line  shows  the  final  computed  path  to  a  cup-like  objea.  while  the 
dimmer  line  is  the  original  path  before  optimization.  The  shaded  area  in  the  uncertainty 
cone  indicates  how  far  the  robot  may  safely  proceed. 


Planner.  At  present  most  of  the  navigation  and  manipulation  planning  is  done  in  this  module.  The 
Planner  has  a  collection  of  procedures,  each  of  which  is  intended  to  achieve  a  goal.  When  executed  to 
achieve  goals,  the  procedures  typically  send  queries,  create  subgoals,  issue  commands,  set  up  monitors, 
specify  temporal  constraints,  and/or  associate  exception  handlers  with  contexts. 

As  an  example,  the  procedure  for  handling  the  cup  collection  goal  does  the  following: 

1.  Adds  approach  object  goaL  The  first  step  is  to  navigate  to  the  vicinity  of  the  target  object 
In  the  course  of  navigation,  the  robot  models  uncertainty  and  watches  out  for  obstacles. 

2.  Sets  up  object  monitor.  This  monitor  watches  for  the  disappearance  of  the  target  objea. 
Temporal  constraints  are  added  to  indicate  that  the  monitor  starts  from  the  beginning  of  the 
cup  collection  goal  and  ends  at  the  beginning  of  the  grasp  cup  goal  (see  below). 

3.  Adds  servo  to  object  goal.  Once  arriving  near  the  object,  the  robot  utilizes  its  wrist  sonar  to 
estimate  its  distance  and  orientation  relative  to  the  object  This  information  is  used  to 
compute  the  locomotion  commands  to  reduce  the  differences  between  the  estimated  and 
desired  distance  and  orientatiort  To  overcome  sensing  and  control  errors,  this  goal  is  re- 
^nerated  recursively  until  the  differences  are  within  acceptable  limits.  This  recursive 
implementation  makes  it  possible  to  break  the  time-consuming  servoing  loop  for  handling 
contingencies. 

4.  Adds  identify  object  goal  to  measure  and  classify  the  object 

5.  Adds  grasp  cup  goal.  If  the  object  is  a  cup.  it  is  grasped  by  a  procedure  specific  to  that  cup. 

A  point  monitor,  which  utilizes  the  base  sonar,  is  set  up  for  checking  if  the  grasping 
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succeeds. 

6.  Adds  approach  receptacle  goal.  Once  picked  up.  the  cup  is  brought  to  the  receptacle. 
However,  temporal  constraints  are  imposed  so  that  the  path  planning  can  begin  once  the 
robot  arrives  near  the  cup. 

7.  Sets  up  holding  monitor.  This  interval  monitor  periodically  reads  the  sensors  on  the  fingers 
to  mate  sure  that  the  cup  does  not  drop  on  the  way  to  the  receptacle. 

8.  Adds  deposit  command  to  drop  off  the  cup  in  the  receptacle. 

9.  Associates  ^ropriate  exception  handlers  to  various  task  tree  nodes. 

User  Interface.  Presently  the  User  Interface  merely  allows  the  user  to  enter  commands,  add  goals,  and 
set  up  monitors.  Facilities  for  supporting  a  friendly  user  interface  are  being  planned. 


5.  Performance 

Our  experience  with  the  testbed  shows  that  TCA  is  a  helpful  tool  for  building  robot  behaviors. 

•  TCA  is  easy  to  use  and  programs  developed  under  TCA  are  usually  easy  to  extend  and 
modify.  This  is  partly  b^use  TCA  encourages  modularity  of  programs.  For  example, 
normal  robot  behaviors,  monitors,  and  exception  har;dling  can  be  developed  separately. 

•  TCA  provides  a  fair  amount  of  expressive  power  to  facilitate  implementing  complex  robot 
behaviors.  For  example,  TCA  makes  it  easy  to  specify  and  control  the  interleaving  of 
{farming  and  execution,  concurrent  monitors,  and  exception  handling. 

Due  to  its  deliberative  nature,  TCA  cannot  be  used  to  implement  low>level  reflex  behaviors  that 
demand  sub-second  responses  to  environmental  changes.  To  minimize  the  interval  between  the  time  an 
exception  is  detected  and  the  time  the  exception  handler  gets  executed,  the  implementors  themselves  must 
adhere  to  a  principle:  each  of  the  robot’s  primitive  actions  must  be  designed  to  finish  in  a  small  time 
frame.  In  other  words,  a  time-consurrring  action  must  be  repeatedly  divided  into  smaller  ones,  so  that 
each  does  not  take  much  time.  'The  reason  is  that  when  an  exception  is  raised,  the  chosen  exception 
handler  might  be  blocked  by  other  ongoing  primitive  actions,  because  of  resource  conflicts.  If  so,  the 
handler  must  wait  for  these  actions  to  finish.  Guaranteed  reactivity  is  an  interesting  research  area  and  we 
plan  to  investigate  it  in  the  near  future. 

Roughly  speaking,  the  robot  system  described  above  is  quite  successful  in  surviving,  collecting  cups, 
and  maintaining  battery  charge.  It  typically  takes  about  3-5  minutes  to  collect  a  cup,  depending  on  the 
difficulty  of  individual  tasks  (e.g..  smaller  cups  usually  demands  mote  time).  If  a  cup  is  placed  away 
from  the  perimeter  of  the  visual  view  and  not  occluded,  the  robot  can  locate  and  collect  it  most  of  the 
time.  Although  the  vision  subsystem  can  be  easily  fooled  by  small  non-cup  objects  (e.g.,  small  box, 
sneaker),  those  objects  are  usually  identified  as  non-cups  by  the  sonar  sensors  when  the  robot  approaches 
the  objects  (but  they  can  result  in  considerable  wasted  time). 

The  robot  system  is  about  twice  as  fast  as  the  previous  sequential  versiotL  This  is  mainly  because  the 
world  map  is  updated  by  an  asynchronous  process;  this  is  a  big  win,  because  image  processing  takes 
much  time.  Another  speed-up  results  from  concurrent  monitors  and  concurrent  planning  and  execution. 

The  robot  system  is  also  relatively  robust  compared  with  the  previous  versioiL  This  is  mainly  because 
the  concurrent  monitors  enable  exceptions  to  be  found  early  and  the  robot  has  a  variety  of  strategies  for 
handling  exceptions.  It  is  also  helped  by  the  reflexive  guarded  conunands  and  their  integration  into  the 
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TCA  mechanisms. 


The  robot,  however,  is  still  susceptible  to  dangers.  These  dangers  mainly  arise  from  the  robot’s 
inability  in  sensing.  For  example,  the  robot  has  no  sensor  to  detect  imminent  arm  collisions  and  prevents 
them  in  advance.  The  vision  processing  is  slow,  so  the  robot  might  use  out-of-date  information  and  make 
wrong  decisions.  Although  these  problems  can  be  minimized  (but  not  overcome)  by  adding  more  sensors 
and  using  faster  hardware,  that  is  not  the  purpose  of  this  work. 

6.  Related  Work 

An  alternative  approach  to  building  reactive  and  robust  robots  is  that  taken  by  the  subsumption 
architecture  [4].  The  main  features  of  this  approach  are  (1)  hard-wired,  layered  robot  behaviors,  (2)  no 
explicit  internal  model  of  the  wodd.  (3)  no  explicit  representation  of  goals  and  plans,  (4)  no  central 
control,  and  (S)  continual  monitoring.  Many  of  these  characteristics  are  shared  by  some  other  approaches, 
such  as  [1]  and  [11].  In  contrast  to  these  architectures.  TCA  has  a  centralized  control  and  makes  the 
notion  of  goals  explicit,  allowing  the  robot  to  reason  about  them.  These  differences  make  TCA  more 
flexible  in  coordinating  complex  robot  behaviors.  The  use  of  explicit  plan  representations  enables  TCA 
to  pre-plan  for  the  future,  not  just  figure  out  "what  to  do  next".  TCA  advocates  selective  monitoring, 
because  sensors  are  often  scarce  resources  and  the  use  of  them  should  be  carefully  scheduled.  These 
differences  result  in  two  architectures  with  very  different  capabilities  [6].  While  the  subsumption 
architecture  is  good  at  handling  low-level  sensor  and  effector  actions  (e.g.,  car  chasing),  it  is  not  yet  clear 
how  complex  behaviors  (e.g.,  planning,  exception  handling)  can  be  coordinated  in  the  architeemre.  On 
the  other  hand,  while  with  TCA  fairly  complex  behaviors  have  been  realized  on  the  Hero  robot,  it  is  not 
well-suited  to  haruUing  low-level  reflex  activities.  Rather  than  competing  architeemres,  however,  it  is 
reasonable  to  combine  the  strengths  of  both  approaches,  for  example,  by  using  the  subsumption 
architecture  for  reflexive  control,  which  talks  to  TCA  for  higher-level  control.  In  fact,  our  experience 
with  the  guarded  move  commands  (see  Section  4)  suggests  that  this  might  be  a  promising  way  to 
implement  robust,  intelligent  robots. 

The  Procedural  Reasoning  System  (PRS)  [7]  consists  of  four  main  components:  a  database  of  beliefs 
about  the  world,  a  goal  stack,  a  library  of  procedural  plans,  and  an  interpreter.  PRS  is  similar  to  TCA  in 
several  aspects.  For  example,  both  are  concerned  with  combining  planful,  reasoned  behaviors  with 
reactivity.  The  goal  stack  and  procedural  plan  representation  used  in  PRS  is  similar  to  our  task  tree 
structure  plus  temporal  constraints.  The  main  difference  between  the  two  systems  is  that  PRS  is  more 
concerned  with  reasoning  and  planning,  while  TCA  mainly  focuses  on  the  execution,  monitoring,  and 
exception  handling. 

The  Reactive  Action  Package  (RAP)  system  [5],  which  is  very  similar  to  HIS,  is  another  work  which 
addresses  reactivity  and  adaptive  execution  of  plans.  Like  TCA,  the  RAP  system  provides  various 
mechanisms  for  supporting  resource  reservation,  temporal  constraiius,  monitoring,  and  exception 
handling.  The  RAP  system,  which  is  a  sequential  system,  is  based  on  the  idea  of  situation-driven 
execution,  much  like  the  subsumption  architecture.  This  viewpoint  is  different  from  that  of  TCA.  While 
supporting  reactivity,  TCA  still  allows  the  robot  to  plan  for  the  future.  For  example,  the  Hero  robot  can 
measure  the  potential  cup.  monitor  its  battery  charge,  and  pre-plan  the  path  to  the  receptacle  concurrendy. 
Both  systems  also  differ  in  the  ways  exceptions  are  handled.  When  exceptions  are  raised,  the  RAP 
system  examines  the  context  at  run-time  to  And  the  appropriate  method  for  re-achieving  the  failed  task, 
while  in  TCA  only  a  simple  search  on  the  task  tree  is  needed. 


The  exception  handling  mechanisms  of  TCA  are  similar  to  those  in  some  programming  languages  such 
as  Ada  [9]  ~  when  an  exception  occurs,  program  execution  is  transferred  to  the  exception  handler  with  a 
matched  name  that  is  closest  to  the  exception  point  in  the  context  (i.e.,  the  runtime  call-stack  in  Ada  or  the 
task  trees  in  TCA).  However,  they  differ  in  three  aspects.  First,  TCA  allows  the  exception  handlers  to 
manipulate  the  task  trees  explicitly,  while  explicit  manipulation  of  the  call-stack  in  Ada  is  prohibited. 
Second,  popping  and  pushing  the  call-stack  is  always  simpler  than  killing  and  adding  new  subtrees, 
because  of  the  temporal  constraints  placed  on  the  task  trees.  Maintaining  the  desired  temporal  constraints 
between  tree  nodes  while  modifying  the  task  trees  is  a  difficult  problem,  which  we  have  not  solved 
completely.  Third,  task  tree  nodes  are  not  killed  while  TCA  is  searching  for  capable  handlers,  so  the 
exception  handlers  can  examine  the  failed  node  and  its  ancestors  to  help  in  debugging  [14]. 

7.  Conclusion 

We  have  designed  and  implemented  TCA,  a  general-purpose  task  control  architecture,  for  the  control  of 
mobile  robots.  TCA  is  designed  to  be  used  for  robots  with  multiple  tasks,  and  limited  computational  and 
physical  resources,  that  operate  in  an  uncertain  and  changing,  but  relatively  benign,  environment  The 
design  of  TCA  is  based  partly  on  experience  gained  from  our  first  version  of  the  Hero  testbed.  That 
version,  developed  in  an  ad  hoc  manner,  had  several  shortcomings,  such  as  brittleness,  unawareness  of 
environmental  changes,  etc.  By  using  TCA,  we  have  re-implemented  the  system  in  a  more  disciplined 
way.  The  current  robot  can  navigate  in  a  changing  (indoor)  environment  avoid  obstacles,  collect  cups  on 
the  floor,  and  at  the  same  time  watch  for  failures  and  contingencies,  recover  from  failures,  and  go 
recharge  when  necessary. 

The  features  of  TCA  that  result  in  the  Hero  robot’s  success  and  that  we  believe,  will  faciliute  the 
building  of  intelligent  robust  robots  are  (1)  distributed  processing,  (2)  lesources,  (3)  task  trees  and 
temporal  constraints.  (4)  concurrent  monitors,  and  (5)  context-dependent  exception  handling.  The 
distributed  environment  enables  robot  activities  such  as  planning,  sensory  data  processing,  monitoring, 
and  plan  execution,  to  be  performed  concurrently.  The  resource  mechanisms  enable  robots  to  schedule 
the  use  of  their  limited  resources.  By  using  the  temporal  mechanisms,  the  user  can  implemem  intelligent 
robots  that  are  able  to  act  on  an  incomplete  plan  when  not  enough  information  is  available  to  make  a 
decision,  and  to  take  advantage  of  parallelism  by  planning  ahead  when  needed  information  is  obtainable. 
Concurrent  monitors,  which  allow  robots  to  acquire  information  from  the  environment  while  executing 
tasks,  gives  robots  the  opportunity  of  reacting  to  environmental  changes  and  changing  their  focus  for 
contingencies  or  opportunities.  The  exception  handling  mechanisms  enable  robots  to  dyiuimically  choose 
context-dependent  strategies  for  handUng  contingencies,  planning  time  failures,  and  execution  time  errors. 
The  mechanisms  also  allow  robots  to  re-use  a  failed  plan  by  making  changes  in  it,  or  even  to  change  their 
focus  completely. 

Another  important  feature  of  TCA  is  that  it  facilitates  modular  and  incremental  design  of  complex  robot 
systems.  In  TCA,  planning,  execution,  monitoring,  and  exception  handling  are  all  logically  and 
functionally  separate  activities.  This  enables  one  to  build  systems  incrementally  -  first  building 
behaviors  that  plan  and  execute,  then  adding  features  (usually  by  adding  new  code  with  few  changes  to 
the  existing  programs)  to  take  advantage  of  concurrency  in  planning  and  execution,  to  monitor  for 
exceptional  situations,  and  to  handle  those  situations  intelligently. 

Despite  these  encouraging  results,  much  more  work  remains  to  be  done.  In  particular,  we  plan  to 
extend  TCA  to  support  various  knowledge-intensive  decision-making  capabilities  [8],  such  as.  scheduling 
various  tasks  based  on  their  urgency  and  relative  cost,  choosing  optimal  plans  based  on  the  analysis  of 
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various  plans'  strength,  limitation,  resource  usages,  time  constraints,  etc. 

Although  building  complex,  robust  robot  systems  is  still  very  much  an  art,  we  believe  that  with  the  use 
of  high-level  architectures,  such  as  TCA,  we  can  make  the  process  easier.  Through  experience  with 
different  robot  systems  (the  CMU  planetary  Rover  also  uses  TCA),  and  analysis  of  the  requiremer.'s  for 
different  environments  and  robot  configurations,  we  are  converging  on  a  set  of  mechanisms  to  support  the 
building  of  such  robot  systems. 
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